Триаж production-инцидента в Kubernetes
Когда использовать: Приложение ведёт себя неправильно в production и нужно смотреть поды, события, логи без переключения вкладок.
Предварительные требования
- kubeconfig с доступом к кластеру — Стандартный
aws eks update-kubeconfigили аналог
Поток
-
Найти нездоровые подыk8s: в контексте
prod-us-east, namespacecheckout, перечисли поды не в состоянии Running. Включи reason + restart count.✓ Скопировано→ Поды показаны с состоянием, reason, перезапусками -
Получить событияПолучи события в этом namespace за последние 30 минут, отсортированные по времени.✓ Скопировано→ Список событий; OOMKilled или ImagePullBackOff видны при наличии
-
Получить логиДля пода с самым последним перезапуском прочитай логи предыдущего контейнера (последние 200 строк).✓ Скопировано→ Стектрейс / причина видны
-
ДиагностироватьСинтезируй: какова вероятная первопричина и что нужно сделать? Будь конкретен.✓ Скопировано→ Конкретный следующий шаг (например, увеличь лимит памяти + выкати)
Итог: Триаж менее чем за 5 минут с указанием имён подов и строк логов.
Подводные камни
- Логи отсутствующего предыдущего контейнера недоступны — Если под перезапускался только один раз, смотри логи текущего контейнера и предыдущего только при сбое
- Неверный контекст — Всегда указывай контекст в каждом вызове; не полагайся на дрейф current-context