Что управляет перемещением pod между узлами в Kubernetes

Управление перемещением Pod между узлами в Kubernetes

В Kubernetes не существует единого контроллера, который бы напрямую управлял перемещением запущенных Pod между узлами. Это принципиальная архитектурная особенность: Pod в Kubernetes считаются эфемерными (immutable) сущностями. Вместо их "перемещения" происходит рекреация (recreation) на новом узле.

Однако, процесс, в результате которого Pod оказывается на новом узле, управляется несколькими компонентами и контроллерами, в зависимости от контекста и причины.

Ключевые компоненты и механизмы

1. Контроллер ReplicaSet / Deployment (Планирование "с нуля")

Основной механизм обеспечения заявленного количества реплик (replicas). Если Pod исчезает с узла (по любой причине), ReplicaSet-контроллер замечает расхождение между желаемым и фактическим состоянием и поручает Scheduler запланировать создание нового Pod на другом доступном узле.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3 # Контроллер стремится поддерживать 3 работающих Pod
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:latest

2. Scheduler (Планировщик - kube-scheduler)

Этот компонент отвечает за первоначальное размещение Pod на узле. При создании нового Pod (в том числе для замены старого) Scheduler оценивает:

• Запросы ресурсов (requests) и лимиты (limits) Pod.
• Политики affinity/anti-affinity (притяжение и отталкивание Pod друг от друга или от узлов).
• Taints и Tolerations (окраски узлов и допуски Pod).
• Прочие условия (дисковое пространство, порты и т.д.).

Решение о выборе узла принимает именно Scheduler.

3. Drain / Cordon (Операции администрирования узлов)

Для планового обслуживания узлов администраторы используют команды kubectl drain и kubectl cordon.

• kubectl cordon <node-name>: Помечает узел как незапланируемый (Unschedulable). Новые Pod на него не попадут.
• kubectl drain <node-name>: Делает следующее:

    1.  Помечает узел как `Unschedulable` (как `cordon`).
    2.  **Изящно завершает (gracefully terminates)** все Pod на этом узле (с соблюдением `terminationGracePeriodSeconds`).
    3.  **ReplicaSet/Deployment-контроллеры** видят, что Pod исчезли, и создают новые на других узлах через **Scheduler**.

# Пример процедуры обслуживания узла
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data
# ... проводим работы на node-1 ...
kubectl uncordon node-1 # Возвращаем узел в пул доступных для планирования

4. Cluster Autoscaler (Автомасштабирование кластера)

В облачных средах может взаимодействовать с механизмами перераспределения Pod. Если после drain на других узлах не хватает ресурсов для Pod, Cluster Autoscaler может автоматически добавить новый узел в кластер, чтобы Scheduler мог разместить на нём Pod.

5. DaemonSet Controller (Специфичный случай)

Для Pod, управляемых DaemonSet, их контроллер стремится запустить по одному Pod на каждом узле (или на узлах, соответствующих селектору). Если добавить новый узел в кластер, DaemonSet Controller сам создаст Pod на этом узле, минуя стандартный Scheduler.

Типичные сценарии "перемещения" Pod

1. Сбой узла: Node Controller (часть kube-controller-manager) обнаруживает недоступность узла и помечает его статусом NotReady. После таймаута Pod на этом узле помечаются как Failed. Их контроллеры (ReplicaSet/Deployment/StatefulSet) создают замену на других узлах.

2. Нехватка ресурсов: Если на узле заканчиваются ресурсы (память/CPU), kubelet может выселить (evict) один или несколько Pod, чтобы защитить стабильность узла. Эти Pod будут пересозданы на других узлах.

3. Ручное или автоматическое масштабирование: При уменьшении количества реплик в Deployment лишние Pod будут удалены. При увеличении — будут созданы новые на подходящих узлах.

Вывод

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