Комментарии 11
Могу ошибаться.
Helm в secrets кладёт весь свой chart в заархивированном состоянии, ну там для версионирования деплоймента.
Я бы начал дебаг не с etcd, а с того, что же такого в этом secrets положил helm на ~2GB.
Хелм хранит релизы в секретах. Каждая версия - это новый секрет. Как описывается в статье, количество секретов достигло 77к штук. И-за этого даже маленькие релизы по объему стали в сумме весить очень много.
А что Вам мешало сразу сделать так? https://helm.sh/docs/topics/advanced/#storage-backends
export HELM_DRIVER=sql
export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changemeКак по мне, etcd - как KV-хранилище Ок, а вот как в него пихать чужеродное от helm-а так тут что-то с архитектурой не Ок.
Релизы через Argocd решили бы проблему?
В теории да, так как основным хранилищем для Арго является GIt. Но тут бы потребовалось клиенту изменять архитектуру деплоя и сбора метрик. Helm, на начальном этапе, казался оптимальным решением :)
Это как раз можно проследить в статье, что решения, которые принимаются в начале, позволяющие ускорить TTM, далее могут сильно повлиять на работу всего сервиса.
Вы бы аккуратнее плюсовали свои статьи. 20 плюсов на 600 просмотров физически невозможно. Для отличных статей это 1 на 100 просмотров, для нормальных 1 на 300. Понимаю, что хочется в топ попасть. Но это больше вас дискредитирует, чем плюс даёт.
а когда масштабировали мастер-ноды до 7, вы не пробовали выносить только control-plane-компоненты, не участвуя всеми в etcd-кворуме? Или цель была именно full HA? Просто складывается ощущение, что лишние ноды только мешали raft-протоколу, а пользы особой не дали
Супер-кейс про etcd и Kubernetes. Очень полезно увидеть реальные проблемы масштабирования и нестандартные решения.
Лечим проблемы Kubernetes на лету по мере масштабирования проекта: опыт команды VK Cloud