Какова вероятность, что после рестарта кластера под займет тот же узел?

Гарантии нет. После рестарта кластера планировщик Kubernetes (kube-scheduler) заново оценивает, куда разместить каждый под, основываясь на текущем состоянии узлов. Вероятность зависит от конфигурации.

Что влияет на размещение:

1. Node Affinity/Anti-Affinity: Это основной инструмент для влияния на решение.

   • requiredDuringSchedulingIgnoredDuringExecution (жесткое правило) – если под был привязан к узлу с такой политикой, он вернется на тот же узел, если тот доступен.
   • preferredDuringSchedulingIgnoredDuringExecution (мягкое правило) – повышает шанс, но не гарантирует.

   spec:
     affinity:
       nodeAffinity:
         preferredDuringSchedulingIgnoredDuringExecution:
         - weight: 1
           preference:
             matchExpressions:
             - key: app-node
               operator: In
               values:
               - "true"

2. Taints и Tolerations: Если на целевом узле есть taint, а у пода нет соответствующего toleration, он туда не попадет.

3. Запросы ресурсов (requests): Узел должен иметь достаточно свободных CPU и памяти.

4. Pod Topology Spread Constraints: Если настроены правила распределения по зонам доступности, они будут иметь приоритет.

Как добиться «липкости»:

• Для stateful-нагрузок (например, БД) использовал StatefulSet в сочетании с PersistentVolume, привязанным к конкретной ноде (например, local volume). После рестарта StatefulSet старается запланировать под с тем же именем (например, db-0) на узел, где находится его том.
• Для других workloads явное указание nodeName – антипаттерн, так как лишает кластер гибкости и отказоустойчивости.