Rак узнать причину крэшлупа

Диагностика причины crashloop в Kubernetes

Чтобы эффективно диагностировать crashloop (состояние, когда контейнер постоянно перезапускается после падения), нужно последовательно исследовать несколько источников информации. Crashloop указывает, что основной процесс контейнера завершается с ненулевым кодом возврата, что заставляет kubelet постоянно его перезапускать.

1. Анализ логов контейнера — первый и основной шаг

Логи показывают, что происходило внутри контейнера перед его завершением. Используйте команды:

# Посмотреть логи текущего запуска падающего пода
kubectl logs <pod-name>

# Посмотреть логи предыдущего запуска (если контейнер уже перезапускался)
kubectl logs <pod-name> --previous

# Для пода с несколькими контейнерами
kubectl logs <pod-name> -c <container-name>

# С флагом --tail для последних N строк
kubectl logs <pod-name> --tail=100

# В реальном времени (пока под пытается запуститься)
kubectl logs <pod-name> -f

В логах ищите:

• Исключения и stack trace (Java, Python, Node.js приложения)
• Fatal errors и сообщения об аварийном завершении
• Ошибки подключения к базам данных, внешним сервисам
• Отсутствие зависимостей или конфигурационных файлов
• Ошибки инициализации приложения

2. Проверка событий (Events) пода

Events предоставляют информацию с точки зрения Kubernetes о том, что происходит с ресурсом:

# Посмотреть события для конкретного пода
kubectl describe pod <pod-name>

# Или только события
kubectl get events --field-selector involvedObject.name=<pod-name>

# Посмотреть события во всем namespace
kubectl get events --namespace <namespace>

В событиях ищите:

• FailedMount — проблемы с монтированием томов
• FailedSync — ошибки синхронизации
• Back-off — kubelet откладывает перезапуск после частых падений
• OOMKilled — контейнер убит из-за нехватки памяти
• FailedPostStartHook — ошибки в postStart хуках

3. Проверка статуса контейнера и кода завершения

# Детальная информация о поде
kubectl describe pod <pod-name>

В секции Containers обратите внимание на:

• Last State и Exit Code — код завершения предыдущего запуска
• Reason — причина завершения (Error, OOMKilled, Completed)
• Restart Count — сколько раз контейнер перезапускался

4. Проверка readiness и liveness проб

Неправильно настроенные пробы могут вызывать бесконечные перезапуски:

# Пример проблемной конфигурации пробы
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5  # Слишком мало для инициализации приложения
  periodSeconds: 3        # Слишком частые проверки

Диагностика:

# Проверьте конфигурацию проб
kubectl get pod <pod-name> -o yaml | grep -A 15 "livenessProbe\|readinessProbe"

# Временно отключите пробы для диагностики
# (измените манифест, удалив livenessProbe)

5. Проверка ресурсов (RAM/CPU)

OOMKilled — частая причина crashloop:

# Проверьте лимиты ресурсов
kubectl describe pod <pod-name> | grep -A 5 "Limits\|Requests"

# Посмотреть метрики потребления (если установлен metrics-server)
kubectl top pod <pod-name>

# Проверить, был ли контейнер убит из-за OOM
kubectl describe pod <pod-name> | grep -i "oom"

6. Диагностика с помощью временного контейнера для отладки

Если логи недостаточно информативны, запустите отладочный контейнер:

# Запуск отладочного пода с отказоустойчивостью
kubectl run debug-pod --image=busybox --restart=Never --rm -it -- sh

# Или добавление ephemeral контейнера (Kubernetes 1.23+)
kubectl debug <pod-name> -it --image=busybox --target=<container-name>

Внутри отладочного контейнера можно:

• Проверить наличие конфигурационных файлов
• Протестировать сетевое подключение
• Проверить точки монтирования

7. Проверка зависимостей и конфигурации

Частые причины crashloop:

• Отсутствующие ConfigMap или Secret, на которые ссылается под
• Неправильные переменные окружения
• Ошибки в точках монтирования томов
• Проблемы с образами контейнеров (отсутствующие теги, проблемы с реестром)

# Проверить, смонтированы ли тома
kubectl exec <pod-name> -- ls /path/to/mount

# Проверить переменные окружения
kubectl exec <pod-name> -- env

# Проверить наличие ConfigMap/Secret
kubectl get configmap,secret

8. Методология диагностики crashloop

1. Быстрая оценка: kubectl get pods — увидеть статус CrashLoopBackOff
2. Логи последней попытки: kubectl logs <pod> --previous
3. Описание пода: kubectl describe pod <pod> — ищем Events и Exit Code
4. Анализ кода завершения:
   • 0 — успешное завершение (возможно, контейнер однозадачный)
   • 1 — общая ошибка приложения
   • 137 — SIGKILL (часто OOMKilled)
   • 143 — SIGTERM (graceful shutdown)
5. Проверка конфигурации: лимиты ресурсов, пробы, зависимости
6. Репродукция проблемы: локальный запуск образа с теми же параметрами

Пример диагностики типичной проблемы

# Видим падающий под
$ kubectl get pods
NAME          READY   STATUS             RESTARTS   AGE
app-pod       0/1     CrashLoopBackOff   5          3m

# Смотрим логи
$ kubectl logs app-pod --previous
Error: Configuration file /app/config.yaml not found

# Проверяем монтирование ConfigMap
$ kubectl describe pod app-pod | grep -A 3 "Mounts"
    Mounts:
      /app/config.yaml from app-config (ro)

# Обнаруживаем, что ConfigMap не существует
$ kubectl get configmap app-config
Error: configmap "app-config" not found

Crashloop почти всегда указывает на проблему внутри контейнера, а не с самой платформой Kubernetes. Систематический подход к диагностике через логи, события и конфигурацию позволяет быстро локализовать и устранить проблему. Для долгосрочной стабильности рекомендую настраивать адекватные лимиты ресурсов, корректные health check пробы, и реализовать graceful shutdown в приложениях.