Обновить
16K+
3
Seyd-Magomed Kuzgov@casssuzy

DevOps/DevSecOps-инженер

11
Рейтинг
Отправить сообщение

kubectl describe pod: как читать вывод, в котором Kubernetes уже написал причину

Уровень сложностиСредний
Время на прочтение22 мин
Охват и читатели11K

Статья о том, как читать kubectl describe pod не как длинный вывод, а как историю жизни Pod«а: кто его создал, куда его пытались поставить, скачался ли image, стартовали ли init containers, что случилось с probes, volumes, restarts и Events.»

Постарался сделать материал дружелюбным для джунов и мидлов, но без упрощения до «введите команду и посмотрите статус». Тут много реальной эксплуатации: Pending, CrashLoopBackOff, ImagePullBackOff, OOMKilled, FailedMount, CreateContainerConfigError, Evicted и любимое «Pod Running, но сервис не работает».

Если вам нужна не вся теория, а быстрая шпаргалка для инцидента — в конце статьи есть компактная схема: что смотреть в kubectl describe pod при Pending, CrashLoopBackOff, ImagePullBackOff, OOMKilled, FailedMount и других типовых состояниях. Можно сразу перейти к ней, сохранить и использовать как чек‑лист. А если хочется понять не только «куда смотреть», но и почему Kubernetes ведёт себя именно так — дальше разберём describe вместе по шагам.

Читать далее

Как мы поймали drift в Kubernetes и зачем после этого перешли на GitOps

Уровень сложностиСредний
Время на прочтение13 мин
Охват и читатели9.3K

История инцидента в продакшене: после планового релиза новая версия сервиса не поднялась, а откат на предыдущую версию тоже не помог. Причина оказалась не в коде, а в расхождении между тем, что было описано в Git, и тем, что реально жило в Kubernetes. Ручная правка ConfigMap несколько месяцев существовала только в кластере, пока очередной релиз не пересоздал поды и не вытащил проблему наружу. Разбираю, как мы нашли причину, почему Git не был настоящим источником правды и зачем после этого перешли на GitOps с Argo CD.

Читать далее

Долгие миграции на старте сервиса — это не startup-проблема. Это ошибка в архитектуре релиза

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели10K

Когда сервис поднимается по 8-15 минут, команда почти всегда начинает крутить одни и те же ручки: увеличивает initialDelaySeconds, добавляет startupProbe, поднимает progressDeadlineSeconds, иногда переносит миграцию в initContainer и считает, что стало «по-кубернетесному». Обычно это не лечение. Это способ аккуратнее завернуть проблему в YAML. Если тяжёлая миграция живёт внутри старта приложения, вы связали жизненный цикл Pod, rollout Deployment и поведение базы в один общий узел. А такие узлы в проде рвутся не там, где их ждут.

Читать далее

Информация

В рейтинге
634-й
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность

Специализация

DevOps-инженер, DevSecOps
Старший
Git
SQL
Python
Linux
Docker
Kubernetes
CI/CD
Базы данных
Terraform
Ansible