Kubernetes не ломается сам: его обычно ломают конфиги, лимиты и доступы

Kubernetes не ломается сам: его обычно ломают конфиги, лимиты и доступы

Контейнеризация решает упаковку приложения, но не отменяет дисциплину вокруг него. В Kubernetes чаще всего страдают три зоны: ресурсы, сеть и права. Если их не контролировать, кластер быстро превращается в дорогой способ запускать «ну вроде работает».

Что проверять в первую очередь:
— requests и limits должны быть заданы осознанно, иначе планировщик будет гадать на кофейной гуще;
— readiness и liveness probe не должны дублировать друг друга без смысла;
— secrets и service accounts нужно разделять по зонам ответственности, а не раздавать всем подряд;
— network policy полезна даже там, где «внутри все свои»;
— поды без ограничений по памяти — это будущий OOM и длинный разбор инцидента.

Отдельно смотрите на конфигурирование через ConfigMap и Secret. Если приложение не умеет жить с изменением переменных или требует ручного рестарта, это не проблема Kubernetes. Это проблема приложения, замаскированная под инфраструктуру.

И еще: не лечите хаос автоскейлингом. Если метрики, лимиты и нагрузочные профили не описаны, HPA просто масштабирует неопределенность. Автоматизация — это не опция, а необходимость, но только после того, как вы зафиксировали базовые правила.

Сначала задайте границы: ресурсы, доступы, проверки здоровья. Потом уже включайте оркестрацию — иначе она начнет оркестрировать ваши ошибки.