Что происходит после падения pod в Kubernetes

Анализ жизненного цикла пода после сбоя

После падения Pod в Kubernetes запускается цепочка скоординированных событий, управляемых Control Plane и kubelet. Этот процесс демонстрирует ключевые принципы Kubernetes: самовосстановление, декларативное управление состоянием и распределенную координацию. Давайте детально разберем этапы.

Этап 1: Детектирование сбоя и обновление статуса

Система обнаруживает падение через один из механизмов liveness-проб (Liveness Probe) или мониторинг со стороны kubelet.

• Пример пробы в манифесте:

  apiVersion: v1
  kind: Pod
  metadata:
    name: myapp-pod
  spec:
    containers:
    - name: myapp-container
      image: myapp:latest
      livenessProbe:
        httpGet:
          path: /health
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 10
        failureThreshold: 3
  

    Если три проверки подряд (`failureThreshold: 3`) на порту 8080 по пути `/health` завершатся неудачей, **kubelet** на узле отметит контейнер как нерабочий.

• kubelet немедленно обновляет статус Pod в API Server, переводя его в состояние Failed для контейнера и Running или Warning для самого пода.

Этап 2: Принятие решения о пересоздании

Далее логика зависит от типа контроллера, которым управляется упавший Pod:

• "Голый" Pod (bare Pod): Если Pod создан напрямую без контроллера (например, через kubectl run), он не будет пересоздан автоматически. Это главная причина всегда использовать контроллеры.
• Pod, управляемый контроллером (ReplicaSet, Deployment, StatefulSet и т.д.): Контроллер постоянно сверяет желаемое состояние (declared state), указанное в манифесте (например, replicas: 3), с фактическим состоянием (current state) в кластере. Обнаружив расхождение, он немедленно инициирует создание нового Pod.

    **На примере ReplicaSet:**
    1.  **ReplicaSet Controller** (часть Controller Manager) получает из API Server событие об изменении статуса Pod.
    2.  Он видит, что текущее количество работоспособных Pod (`readyReplicas`) меньше желаемого (`replicas`).
    3.  Контроллер через API Server создает **новый Pod объект**. Важно понимать, что это **абсолютно новый Pod** со свежесгенерированным именем и новым IP-адресом.

Этап 3: Планирование и запуск нового Pod

Созданный API Server объект Pod попадает в очередь планировщика (kube-scheduler):

1. Планирование (Scheduling): Scheduler анализирует требования Pod (resources, nodeSelector, affinity/anti-affinity правила) и выбирает подходящий узел (Node), где достаточно ресурсов.
2. Назначение: Scheduler обновляет объект Pod в API Server, записывая в него имя выбранного узла (nodeName).
3. Запуск: kubelet на назначенном узле, наблюдая за API Server, обнаруживает, что ему назначен новый Pod. Он скачивает образы контейнеров, монтирует тома и запускает контейнер(ы).

Этап 4: "Разогрев" и проверка работоспособности

Новый Pod не сразу начинает принимать трафик. Здесь вступают в действие readiness-пробы (Readiness Probe):

• Пока проба не успешна, Endpoint Controller (часть Controller Manager) не добавит IP-адрес Pod в соответствующий Endpoint объект сервиса (Service).
• Kube-proxy на каждом узле, отслеживая изменения Endpoints, обновляет правила iptables/IPVS. Только после этого трафик от Service начинает маршрутизироваться на новый Pod.

Этап 5: Очистка упавшего Pod

Старый, упавший Pod объект обычно остается в системе в состоянии Failed. Его окончательная судьба зависит от конфигурации:

• Для самостоятельных Pod — он остается, пока его не удалят вручную.
• Для Pod, управляемых контроллерами, старые реплики (Failed или Succeeded) собираются сборщиком мусора (Garbage Collector) согласно настройкам политики истории (revisionHistoryLimit в Deployments) или политики удаления.

Ключевые факторы, влияющие на поведение

• RestartPolicy: Определяет, будет ли kubelet перезапускать контейнеры внутри того же Pod. Для рабочих нагрузок обычно стоит Always (по умолчанию для Deployments) или OnFailure. Это перезапуск контейнера, а не создание нового Pod.
• Backoff-механизм: При частых падениях и перезапусках kubelet увеличивает задержку (экспоненциальная отсрочка) между перезапусками, чтобы избежать бесконечных циклов и нагрузки на систему.
• Quotas и лимиты: Если в кластере исчерпаны ресурсы (CPU, Memory) или достигнут лимит на количество Pod, новый Pod будет оставаться в состоянии Pending.

Итог: Падение Pod — штатная ситуация, для обработки которой Kubernetes задействует скоординированную работу нескольких компонентов (kubelet, API Server, Scheduler, Controller Manager, Garbage Collector). Цель — автоматически и максимально быстро привести кластер в соответствие с декларативным желаемым состоянием, обеспечивая отказоустойчивость приложения.