Дебаггинг в Kubernetes: инструменты и подходы

Когда приложение в Kubernetes «падает», проблема редко бывает только в коде. Причина может скрываться в сети, ресурсах, конфигурации, readiness/liveness probes или самом кластере. Ниже — практичный набор инструментов и подходов, который помогает быстрее находить источник сбоя.

Начинайте с kubectl describe

Это базовая точка входа для диагностики Pod, Deployment, Node или Service.

kubectl describe pod 

Покажет события: CrashLoopBackOff, ошибки монтирования томов, проблемы с image pull, нехватку ресурсов и статусы probe. Часто именно здесь уже видна причина.

Смотрите логи контейнера 📜

Для текущих логов:

kubectl logs 

Если контейнер перезапускается:

kubectl logs  --previous

Для мультиконтейнерных Pod:

kubectl logs  -c 

Это особенно важно при ошибках старта, когда приложение падает раньше, чем успевает обработать трафик.

Проверяйте события кластера

Иногда проблема не в приложении, а в окружении:

kubectl get events --sort-by=.metadata.creationTimestamp

Так можно быстро заметить проблемы с scheduler, PVC, сетью, нодами или лимитами.

Используйте kubectl exec для проверки внутри контейнера 🔍

Позволяет убедиться, что переменные окружения, конфиги, DNS и доступ к зависимостям работают как ожидается:

kubectl exec -it  -- sh

Проверьте:

• доступность сервисов через curl
• DNS-резолвинг
• наличие файлов конфигурации
• открытые порты и сертификаты

Эфемерные контейнеры для отладки 🛠️

Если основной контейнер минималистичный и в нем нет shell или утилит, используйте debug-контейнер:

kubectl debug -it  --image=busybox

Это удобный способ исследовать сеть, файловую систему и окружение без пересборки образа.

Проверяйте ресурсы и состояние нод 📈

OOMKilled, throttling CPU и нехватка памяти — частые причины нестабильности:

kubectl top pod
kubectl top node

Если приложение регулярно упирается в лимиты, проблема может быть не в логике, а в неверных requests/limits.

Диагностируйте сеть и Service 🌐

Если Pod работает, но трафик не доходит:

• проверьте Endpoints у Service
• убедитесь, что labels у Pod совпадают с selector Service
• проверьте Ingress, NetworkPolicy и порт контейнера

Команды:

kubectl get svc
kubectl get endpoints
kubectl describe ingress 

Сверяйте probes

Неправильно настроенные livenessProbe и readinessProbe могут «ломать» даже рабочее приложение. Типичные ошибки:

• слишком короткий initialDelaySeconds
• неверный path/port
• проверка сервиса до его полной инициализации

Системный подход к дебагу ✅

Эффективная последовательность обычно такая:

1. Проверить статус Pod
2. Посмотреть describe и events
3. Изучить логи текущего и предыдущего контейнера
4. Проверить сеть, конфиг и зависимости через exec/debug
5. Сопоставить поведение с лимитами ресурсов и probes

Главная ошибка при дебаггинге Kubernetes — сразу искать баг в коде, игнорируя инфраструктурный слой. В Kubernetes приложение живет в цепочке зависимостей, и сбой может находиться на любом уровне.

👀 В конце дня выигрывает не тот, кто знает больше команд, а тот, кто идет по гипотезам последовательно.

Подборку полезных каналов про IT стоит посмотреть — там часто публикуют практические кейсы, разборы инцидентов и рабочие шпаргалки по Kubernetes.

🗣 Подборки каналов
🧠 Каталог ботов и приложений
🗺 Навигация