Лечим проблемы Kubernetes по мере масштабирования проекта: разбор от VK Cloud

Один из клиентов VK Cloud решил масштабировать BI-сервис на Kubernetes с 1 000 до 5 000 подов. Но уже в первый месяц достиг 5 000 и столкнулся с задержками в etcd. Вместо стабильного кластера — лаги, нестабильность и ошибки в работе Kubernetes.

Почему масштабирование не помогло. Изначально гипотеза была в увеличении количества мастер-нод с 5 до 7. Но производительность только упала: etcd — это не просто распределенное хранилище, оно требует кворума для каждой записи. Чем больше нод, тем дольше запись. В чтении тоже не все гладко: работает через RAFT и одного лидера, даже если у вас 7 нод.

Что сработало: шардирование etcd. Вынесли часть данных (/events) из основного etcd в отдельный экземпляр с быстрым диском. Это снизило нагрузку на кластер и повысило стабильность.

На 10 000 подов — уперлись в квоту. По умолчанию квота etcd — 2 Гб. При превышении — ошибка mvcc: database space exceeded. Расширили до 8 Гб, как рекомендует etcd, и все заработало.

� 25 000 подов — grpc переполнен. Ошибки Helm при запросе helm list -A: размер сообщения > 2 Гб. Причина — в etcd хранилось по 7–8 релизов на каждого из 25 000 клиентов. Почистили историю релизов, выставили --history-max=2 и удалили тестовые namespace.

17 000 подов — но etcd продолжает деградировать. Снижение количества подов не помогло. Количество объектов в etcd продолжало расти из-за неочищенных секретов. Анализ показал: 63% etcd занимают secrets от Helm. Миграция secrets в Postgres вернула кластер в норму.

Выводы �

Kubernetes ≠ масштаб по умолчанию. Без глубокой экспертизы мелкие проблемы становятся системными.

etcd — узкое горлышко при масштабировании. Даже «правильная» архитектура может не выдержать роста.

Настройка Helm, шардирование, контроль KV-объектов и ограничение истории релизов обязательны для больших кластеров.

@digitize_IT — мнения и управленческий опыт ИТ-лидеров
#vkcloud #kubernetes