Kubernetes ломает не приложение, а дисциплину вокруг него

Контейнеризация сама по себе не решает хаос, она просто делает его повторяемым. В Kubernetes это видно особенно быстро: если сервисы собраны без нормальных границ ответственности, оркестратор лишь ускорит распространение проблем.

Базовый чек-лист перед выкаткой:
— один контейнер — один процесс;
— healthcheck не должен врать ради «зелёной» панели;
— ресурсы requests/limits задаются осознанно, а не «на глаз»;
— конфигурация и секреты не хранятся в образе;
— логика graceful shutdown проверяется отдельно, иначе получаете потерянные запросы и странные рестарты.

Отдельный класс ошибок — слепая вера в автоскейлинг. Если приложение упирается в БД, очередь или внешний API, увеличение числа Pod'ов только ускоряет деградацию. То же самое с readiness/liveness: неправильная проверка превращает нормальный деплой в бесконечный цикл перезапусков. Код работает, но есть нюансы.

Ещё одна зона риска — сеть и доступы. Ingress, Service, NetworkPolicy и RBAC надо проектировать вместе, а не собирать по принципу «потом докрутим». Безопасность начинается с доступа, а доступ в кластере — это ещё и про минимизацию радиуса поражения.

Если хотите стабильный Kubernetes, начинайте не с YAML, а с контракта между приложением, сетью и наблюдаемостью. Автоматизация — это не опция, а необходимость.