💥 Kubernetes хаос и как его приручить

Все красиво, пока не падает прод. А потом ты открываешь kubectl get pods и видишь 37 подов в статусе CrashLoopBackOff.
Kubernetes вроде как должен “самоисцеляться”, но иногда он просто сидит и смотрит, как всё горит 🔥

Вот три типичных источника хаоса и как их быстро приручить:

1. Liveness / Readiness пробы
Когда они настроены неправильно - поды убиваются зря.
👉 Проверь, что readinessProbe не стреляется слишком часто, и добавь initialDelaySeconds.
Удивительно, как часто это спасает от самоуничтожения.

2. OOMKilled
Если ты видишь это в kubectl describe pod - у тебя проблема с лимитами.
👉 Поставь requests чуть ниже среднего потребления, limits - чуть выше пика.
И не забудь включить VerticalPodAutoscaler - пусть сам подскажет реальные цифры.

3. NetworkPolicies и DNS
Часто блокируются сервисы внутри кластера, особенно CoreDNS.
👉 Минимальный тест: kubectl exec -it pod -- nslookup kubernetes.default.
Если не работает - смотри NetworkPolicy и iptables в CNI.

Подпишись 👉@devopslib

💥 Kubernetes хаос и решения. Часть 2 - «Боль автообновлений»

Если у тебя в кластере внезапно всё «упало» ночью, а утром тебя встретил alert с фразой “Pods not ready” - скорее всего, виноваты автообновления.

Сценарий классический:

- Включен auto-upgrade для node pool в GKE/EKS/AKS.
- Cloud-провайдер решил, что пора обновить kubelet и runtime.
- Worker-ноды перезагрузились, pods пошли в Terminating, Pending, а кластер стал частично неработоспособным.

Почему так происходит:

- Не настроены PodDisruptionBudgets (PDB).
- Нет стратегии drain с учётом приоритета workloads.
- Stateful приложения (Postgres, Kafka, Redis) теряют лидерство и консистентность.
- Контроллеры не успевают пересоздавать pod'ы из-за лимитов ресурсов или ошибок readinessProbe.

Как лечить:

1. Отключи автообновления для node pool - обновляй вручную.
2. Введи maintenance window, чтобы обновления шли только в заданные часы.
3. Определи PDB для всех важных pods - не более 1-2 одновременно недоступных.
4. Используй drain-сервис например, kured с контролем через annotations.
5. Тестируй обновления на staging-кластере - симулируй rolling drain.

Подпишись 👉@devopslib

🚨 Когда “сам себя перезапустил” — это не баг, а фича

Недавно один под обетом «никогда больше не трогать продакшн ночью» всё-таки зашёл “на минутку”.
Проверил pods, увидел CrashLoopBackOff, сделал kubectl delete pod, и - чудо - всё ожило!
Только через 10 минут понял, что просто три раза подряд перезапустил контейнер с тем же багом.

Moral of the story:
Не каждый автоперезапуск - спасение. Иногда Kubernetes просто смотрит на тебя и думает:

“Я делаю, что могу, но ты уверен, что хочешь, чтобы это продолжалось?”

🧠 Совет:
Если контейнер падает постоянно - не трогай pod. Смотри kubectl describe pod и kubectl logs -p.
Возможно, виноват init-контейнер, readiness-проба или ошибка в startup-скрипте.
И да - логи с -p спасают, когда под уже ушёл на перезапуск.

Подпишись 👉@devopslib