Что делать, если невозможно избежать простоя при обновлении кластера Kubernetes?

Полностью бесшовное обновление кластера (особенно control plane) — сложная задача, но downtime можно минимизировать до нескольких секунд или сделать его незаметным для пользователей, используя правильные стратегии.

1. Стратегии обновления нод (Node Pool):

• Rolling Update (по умолчанию в managed-сервисах): Провайдер (GKE, EKS, AKS) последовательно дренирует (drain) и обновляет ноды по одной, перемещая поды на другие ноды. Для этого необходимо иметь достаточный запас ресурсов в кластере.
• Blue-Green нод: Создаётся новый пул нод (Green) с новой версией, на него постепенно перемещаются поды (например, с помощью пересоздания Deployment'ов). После проверки старый пул (Blue) удаляется.

2. Стратегии деплоя приложений (чтобы они пережили обновление нод): Ключ к отсутствию простоя — в том, как обновляются сами приложения.

• PodDisruptionBudget (PDB): Гарантирует, что во время добровольных сбоев (как drain ноды) будет доступно минимальное количество подов.

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

• Readiness Probes: Критически важны. Kubelet не направляет трафик на под, пока его readiness-проба не станет успешной. Это гарантирует, что на новую версию трафик пойдет только когда она полностью готова.
• Множественные реплики: Приложение должно работать как минимум в 2-3 репликах, разнесённых по разным нодам (используйте podAntiAffinity).

3. Обновление control plane (в managed-сервисах): В GKE/EKS/AKS обновление master-нод происходит автоматически и, как правило, не влияет на работоспособность запущенных подов и сервисов. Кратковременный downtime (секунды) может возникнуть только для операций управления API (например, kubectl get pods).

4. План действий для минимизации воздействия:

1. Протестировать на staging: Всегда сначала обновлять тестовый кластер, идентичный продакшену.
2. Запланировать на время наименьшей нагрузки: Использовать maintenance windows.
3. Уведомить команды: Сообщить о плановых работах.
4. Иметь rollback-план: Заранее подготовить конфигурацию для быстрого отката к предыдущей версии (например, через Git-теги и ArgoCD).
5. Мониторинг: Во время обновления внимательно следить за метриками (Grafana), логами и алертами (Alertmanager).

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