Kubernetes ломается не из-за оркестрации, а из-за грязных конфигов и слабых границ доступа

Kubernetes ломается не из-за оркестрации, а из-за грязных конфигов и слабых границ доступа

В кластере почти всегда всплывают одни и те же ошибки:
— контейнер жив, но приложение не готово принимать трафик;
— liveness убивает под при нагрузкой, потому что healthcheck проверяет не то;
— requests и limits выставлены “на глаз”, после чего scheduler начинает гадать за вас;
— один namespace превращают в склад всех сервисов, а потом удивляются шуму и конфликтам.

Дальше начинается классика продакшена: секреты лежат рядом с обычными переменными, сервисы общаются без явных политик, а права выданы шире, чем нужно для работы. Безопасность начинается с доступа, а не с надежды на порядочность манифеста. RBAC, NetworkPolicy и разделение namespace — не бюрократия, а минимальная гигиена.

Отдельно смотрите на rollout и отказоустойчивость. Если у pod нет нормального readiness, он попадет в балансировку раньше времени. Если нет anti-affinity и PDB, один узел может уронить слишком много реплик. Если нет observability, вы узнаете о проблеме от пользователя — а это уже не мониторинг, а археология.

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