Какой шанс, что после рестарта кластера, pod займет тот же узел?

Вероятность повторного размещения Pod на том же узле после рестарта кластера

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

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

1. Отсутствие состояния у планировщика: kube-scheduler не хранит историю размещения Pod. После рестарта кластера все Pod'ы переходят в состояние Pending, и планировщик заново оценивает все узлы для каждого Pod по стандартному алгоритму.
2. Алгоритм планирования: Планировщик оценивает узлы, фильтруя непригодные и оценивая оставшиеся по набору правил (scoring). Решение принимается на основе текущих метрик: доступность ресурсов (CPU, memory), правила taints/tolerations, node affinity/anti-affinity и т.д.
3. Параллельное планирование: При массовом пересоздании Pod'ов планировщик обрабатывает их конкурентно, что делает случайное распределение еще более вероятным.

Как гарантировать или повысить вероятность

Чтобы Pod гарантированно или с высокой вероятностью вернулся на конкретный узел, необходимо использовать механизмы привязки:

1. Node Selector / Node Affinity

Жесткое требование (requiredDuringSchedulingIgnoredDuringExecution) или предпочтение (preferredDuringSchedulingIgnoredDuringExecution) к меткам узла.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: app-node
            operator: In
            values:
            - special-node

2. Node Name

Прямое указание имени узла в спецификации Pod (используется редко, так как лишает гибкости).

spec:
  nodeName: k8s-node-01

3. Статические Pod'ы (Static Pods)

Управляются kubelet напрямую через манифесты на узле. После рестарта узла kubelet сам воссоздаст Pod на том же месте.

# Манифест размещается, например, в /etc/kubernetes/manifests/

4. Persistent Volume (PV) с Local Volume

Если Pod использует PersistentVolume с типом local, и том привязан к конкретному узлу, планировщик обязан разместить Pod на этом узле, чтобы тот мог подключить том.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/data
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - k8s-node-02 # Жесткая привязка тома к узлу

Практический пример и расчет вероятности

Допустим, в кластере 10 однородных узлов, и нет никаких правил affinity/anti-affinity. Вероятность случайного попадания Pod на конкретный узел равна: P = 1 / N, где N — число подходящих узлов.

• Для одного Pod: P = 1/10 = 10%.
• Для 5 одинаковых Pod'ов (например, из Deployment), которые должны разместиться на разных узлах (из-за anti-affinity по умолчанию у Pod'ов одного контроллера), вероятность того, что все вернутся на свои старые узлы, практически нулевая, так как планировщик будет распределять их последовательно, и доступные узлы будут меняться.

Вывод

Без явной конфигурации шанс практически равен случайному распределению (1/N). В продакшн-среде полагаться на это нельзя. Если требуется постоянство размещения (для локального кэша, низкоуровневой оптимизации или работы с оборудованием), необходимо использовать:

• Node Affinity (предпочтительный способ)
• Local PersistentVolumes (для stateful-нагрузок)
• DaemonSet (если Pod должен быть на каждом/конкретном узле по определению)

Таким образом, Kubernetes по дизайну рассматривает узлы как заменяемый ресурс, и разработчик должен явно указывать требования к размещению, если они выходят за рамки стандартного поведения.