<b>Kubernetes ломается не «в целом», а в пяти предсказуемых местах</b>

<b>Kubernetes ломается не «в целом», а в пяти предсказуемых местах</b>

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

Проверяйте базу:
— requests и limits должны быть осмысленными, а не «на глаз»
— readiness и liveness probes обязаны отражать реальное состояние приложения
— ресурсы для системных компонентов нельзя оставлять «по умолчанию»
— один Pod не должен быть единственной точкой отказа
— storage и сеть нужно тестировать под отказом, а не в happy path

Отдельно смотрите на конфиги деплоя. Ошибки в env, секретах, affinity, taints и nodeSelector обычно всплывают не сразу, а когда сервис уже успел попасть в кривой rollout. Код работает, но есть нюансы: в Kubernetes нюансы любят становиться инцидентами.

Полезная привычка — описывать кластер как набор ограничений, а не как «магическую платформу». Тогда у вас появляются понятные SLO, предсказуемый failover и меньше сюрпризов от автоматики.

Мониторинг должен быть проактивным, а не реактивным: если вы видите проблему только после падения Pod’а, значит, у вас пока не мониторинг, а археология.