Как обеспечивается отказоустойчивость узлов (нод) в Kubernetes?

Отказоустойчивость узлов в Kubernetes обеспечивается за счёт архитектуры самого кластера и дополнительных практик.

1. Архитектура Control Plane:

• Разворачиваю кластер с несколькими нодами control plane (минимум 3 для кворума). В управляемых сервисах (EKS, GKE) это обеспечивается провайдером.
• Компоненты control plane (API Server, etcd, Scheduler, Controller Manager) реплицированы и распределены по нодам.

2. Отказоустойчивость рабочих нод (Worker Nodes):

• Группы нод (Node Groups): Использую Managed Node Groups в EKS или Instance Groups в GKE, которые автоматически пересоздают упавшие ноды.
• Распределение по зонам: Размещаю ноды как минимум в двух, а лучше в трёх Availability Zones (AZ) облачного провайдера. Это защищает от падения целой зоны.
• Anti-affinity для системных подов: Настраиваю PodAntiAffinity для критичных системных компонентов (Ingress-контроллеры, операторы), чтобы они не оказались на одной ноде.

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  name: nginx-ingress
  spec:
  replicas: 3
  selector:
  matchLabels:
    app: ingress
  template:
  spec:
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - ingress
          topologyKey: kubernetes.io/hostname

3. Мониторинг и самовосстановление:

• Настраиваю алерты в Prometheus на метрики нод: kube_node_status_condition{condition="Ready",status="false"} или node_cpu_utilisation > 90%.
• Использую Pod Disruption Budgets (PDB) для гарантии доступности приложения во время плановых работ (обновление нод, масштабирование). PDB указывает, сколько реплик приложения могут быть недоступны одновременно.

  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
  name: app-pdb
  spec:
  minAvailable: 2  # Минимум 2 пода должны оставаться доступными
  selector:
  matchLabels:
    app: my-critical-app

4. Стратегия обновления нод:

• Использую механизм rolling update для групп нод, который последовательно дренирует (cordon & drain) и пересоздаёт ноды с новым образом, минимизируя влияние на поды.