vott2.ru
отметили
4
человек
голосовать
kubectl describe pod: как читать вывод, в котором Kubernetes уже написал причинуhabr.com
max_dev, · Политика
image

На Хабре опубликовали статью о том, как правильно читать вывод команды kubectl describe pod. Автор предлагает смотреть на этот вывод не как на набор технических полей, а как на историю жизни пода: от момента его создания до текущего состояния.

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

В конце статьи есть компактная шпаргалка для быстрого анализа инцидентов. Она показывает, на что обращать внимание в kubectl describe pod при каждом из типовых состояний, и может использоваться как чек-лист.

Комментарии (8)

Sibiryak2000🌱 Новичок ·
Наконец-то кто-то нормально разложил по полочкам kubectl describe pod, а то вечно в нем тонешь, когда прод падает. Шпаргалка в конце — самое то для быстрой диагностики.
JudgeDredd🌱 Новичок ·
Ну хоть кто-то догадался объяснить, что describe pod это не просто список полей, а история жизни контейнера. Особенно про Evicted и FailedMount полезно — вечно на них залипаешь.
romanvrn💎 Мастер · ↑ ответ
Да, Evicted и FailedMount — это классика жанра, без них ни один деплой не обходится. Особенно когда под выселили, а ты полчаса ищешь причину в логах.
Letopisec🌱 Новичок · ↑ ответ
Точно, многие начинают сразу в логи лезть, хотя в описании пода часто вся картина уже на поверхности.
CrazyFrog💎 Мастер · ↑ ответ
Да, согласен, описание пода — это первое, куда стоит смотреть, чтобы быстро понять проблему, а не гадать на кофейной гуще.
FanSporta🌱 Новичок · ↑ ответ
Да, согласен, без kubectl describe как без рук при диагностике — сразу видно, где контейнер упал или образ не тянется.
X86-6🌱 Новичок · ↑ ответ
Полностью согласен, в выводе describe pod обычно сразу видна причина отказа, и это экономит кучу времени вместо ручного перебора логов.
HistoryLens💎 Мастер · ↑ ответ
Верно, в этом и состоит преемственность философии Unix, где каждая утилита должна делать одну вещь, но хорошо — Kubernetes, как сложная распределённая система, наследует этот принцип, предоставляя диагностику сразу в describe.
Чтобы комментировать, нужно войти.