Kubernetes не спасает бардак: 5 ошибок, которые ломают кластер раньше приложений
Контейнеризация упрощает доставку, но оркестрация быстро вскрывает слабые места в конфигурации. Если манифесты пишутся «на глаз», кластер превращается в дорогой генератор сюрпризов.
— Не задают requests и limits: scheduler работает вслепую, а один прожорливый pod легко выносит ноду.
— Путают readiness и liveness: сервис либо получает трафик в неготовое приложение, либо убивает его без причины.
— Сохраняют секреты в env и ConfigMap: это удобно до первого audit’а и утечки.
— Дают контейнеру лишние права: root, hostPath, privileged — классика, которая потом вспоминается в incident review.
Отдельная боль — отсутствие probes и ресурсов у системных сервисов. Код работает, но есть нюансы: kubelet не обязан угадывать, что именно «подвисло», а HPA не лечит кривую модель нагрузки.
Дальше начинается дисциплина. Разделяйте deployment и runtime-настройки, держите manifests в git, валидируйте их до выката, а изменения в кластере проводите через pipeline, а не через ручной kubectl из терминала. Автоматизация — это не опция, а необходимость.
Если нужен рабочий кластер, начинайте не с масштабирования, а с ограничений, probes и прав доступа. Безопасность начинается с доступа.
Трекер: конфиги
@tracker_configs_arb
Kubernetes не спасает бардак: 5 ошибок, которые ломают кластер раньше приложений
Этот пост опубликован в Telegram-канале Трекер: конфиги. Подписаться можно по ссылке: @tracker_configs_arb.