При каких условиях Pod упадет

Условия завершения работы Pod (Crash/Failure)

Pod в Kubernetes может завершить работу ("упасть") по множеству причин, которые можно разделить на несколько категорий. Понимание этих условий критически важно для построения отказоустойчивых систем.

1. Проблемы на уровне контейнера (Container-Level Failures)

Это наиболее частые причины падения Pod.

• Завершение основного процесса с ненулевым кодом выхода: Если основной процесс (PID 1) внутри контейнера завершается с кодом ошибки (не равным 0), контейнер останавливается, что приводит к падению Pod.

  # Пример: Простой скрипт, который "падает"
  # Dockerfile
  CMD ["sh", "-c", "exit 1"] # Контейнер сразу завершится с ошибкой
  

• Нарушение лимитов ресурсов (OOMKill): Если контейнер превышает установленный лимит памяти (limits.memory), ядро Linux (oom_killer) принудительно завершит процесс. В событиях Pod (kubectl describe pod) будет указана причина OOMKilled.

  # Пример манифеста, провоцирующего OOM
  resources:
    limits:
      memory: "100Mi"   # Жесткий лимит
    requests:
      memory: "50Mi"
  # Если приложение попытается использовать >100Mi, оно будет убито.
  

• Истечение таймаута готовности/живучести (Liveness/Readiness Probe Failure):

    *   **Liveness Probe:** Если проверки живучести проваливаются несколько раз подряд (значения `failureThreshold`), kubelet перезапускает контейнер. Если перезапуски не помогают (с учетом `restartPolicy`), Pod переходит в состояние `CrashLoopBackOff`.

```yaml
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 5
  failureThreshold: 3 # После 3-х провалов подряд - контейнер будет убит.
```

    *   **Readiness Probe:** Сама по себе не убивает контейнер, но исключает Pod из балансировщика нагрузки. Однако, если она проваливается постоянно, это может быть симптомом проблемы, ведущей к последующему падению.

• Ошибки запуска (Startup Probe Failure): Аналогично livenessProbe, но используется для приложений с долгим стартом. Её провал также приводит к перезапуску контейнера.

2. Проблемы на уровне Pod (Pod-Level Failures)

• Ошибки инициализации (Init Container Failure): Если любой из init-контейнеров завершается с ошибкой, весь Pod не запустится. Kubelet будет перезапускать упавший init-контейнер в соответствии с политикой перезапуска Pod (restartPolicy).

  initContainers:
  - name: init-db
    image: busybox
    command: ['sh', '-c', 'exit 1'] # Pod никогда не перейдет в состояние Running
  containers:
  - name: app
    image: nginx
  

• Политика перезапуска (RestartPolicy): Поведение Pod при падении контейнера зависит от этой политики.

    *   `Always` (по умолчанию): Контейнер всегда перезапускается.
    *   `OnFailure`: Перезапуск только при завершении с ошибкой (ненулевой код).
    *   `Never`: Контейнер никогда не перезапускается. Pod останется в состоянии `Error` с упавшим контейнером.

3. Проблемы на уровне узла и планировщика (Node & Scheduler Issues)

• Вытеснение (Eviction): Узел может вытеснить Pod при нехватке ресурсов (памяти, диска). Pod будет помечен как Failed и, в зависимости от контроллера (например, Deployment), пересоздан на другом узле.
• Недоступность узла (Node Failure): Если узел становится недоступным (network partition, hardware failure), kubelet-apiserver связь прерывается. Через --node-monitor-grace-period (по умолчанию 40с) контрольная плоскость помечает узел как NotReady и удаляет все Podы на нем. Затем контроллеры (Deployment, StatefulSet) воссоздают их на других узлах.
• Несоответствие селекторам узла/толерантности (Node Selector/Affinity/Taint): Pod может быть запланирован, но если условия изменились или были заданы неверно, он может оставаться в состоянии Pending бесконечно, что косвенно является "отказом" запуска.

4. Внешние и системные причины

• Ошибки монтирования томов (Volume Mount Errors): Если не удается смонтировать PersistentVolumeClaim (например, из-за несуществующего PVC, проблем с CSI-драйвером или бэкендом хранилища), контейнер не запустится. В событиях Pod будут ошибки типа FailedMount.
• Ошибки образа (Image Errors): Невозможность pull образа (ImagePullBackOff) из-за неверного имени, отсутствия прав в registry или проблем сети.
• Нарушение политик безопасности (Security Policy Violation): Если Pod пытается выполнить действие, запрещенное PodSecurityPolicy (в устаревших версиях) или Pod Security Admission, он не будет создан или будет завершен при попытке нарушения.
• Ручное удаление (Manual Deletion): Команда kubectl delete pod приводит к его graceful termination и последующему удалению. Для Pod, управляемого контроллером (например, Deployment), это вызовет пересоздание нового Pod.

Ключевые индикаторы состояния Pod

Для диагностики используйте:

# Основное состояние
kubectl get pods
# Возможные статусы: Pending, Running, Succeeded, Failed, CrashLoopBackOff, ImagePullBackOff, Error, Terminating

# Детальная информация и события (ОЧЕНЬ ВАЖНО)
kubectl describe pod <pod-name>

# Логи упавшего контейнера
kubectl logs <pod-name> --previous

Итог: Pod — это эфемерная сущность, и его падение является нормальным механизмом обработки сбоев в Kubernetes. Ключевая задача DevOps-инженера — правильно настраивать probes, лимиты ресурсов, политики перезапуска и использовать контроллеры (Deployments, StatefulSets) для обеспечения автоматического самовосстановления приложения при возникновении большинства из описанных условий. Мониторинг событий (kubectl describe) и логов — основа быстрой диагностики.