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

Стратегии минимизации и управления простоем при обновлении кластера Kubernetes

При обновлении кластера Kubernetes (особенно control plane) полный zero-downtime может быть недостижим, особенно в standalone-кластерах без высокой доступности control plane. Однако цель — свести простой к минимуму и сделать его управляемым. Вот комплексный подход, который я применяю на практике.

1. Планирование и подготовка: снижение рисков до обновления

Перед любыми действиями критически важна подготовка.

• Тщательное изучение changelog и release notes: Анализируем breaking changes, deprecated API, изменения в работе компонентов. Особое внимание — версиям kube-apiserver, etcd, network plugins (CNI).
• Резервное копирование критических состояний:

  # Резервное копирование etcd (на примере кластера, развернутого с kubeadm)
  ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /var/lib/etcd/etcd-snapshot-$(date +%Y%m%d).db
  
  # Экспорт ресурсов кластера через kubectl
  kubectl get all --all-namespaces -o yaml > cluster-state-backup-$(date +%Y%m%d).yaml
  

• Тестирование в изолированном окружении: Обновление сначала проводится на staging- или dev-кластере, максимально похожем на production. Используются инструменты вроде kubeadm или специфичные для провайдера (GKE, EKS, AKS имеют свои каналы обновления).
• Коммуникация: Четко согласовываем окно простоя (maintenance window) со всеми заинтересованными сторонами (разработчики, бизнес), информируем о планируемой длительности и потенциальном влиянии.

2. Стратегия обновления рабочих узлов (Node Pool) — ключ к доступности приложений

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

• Использование стратегии Rolling Update для nodepool: Большинство облачных провайдеров и инструментов (например, kops) поддерживают поочередное обновление узлов.

    *   Создается новый узел с обновленной версией.
    *   На старом узле выполняется **cordon** (запрет планирования новых подов) и **drain** (аккуратное удаление подов с соблюдением `PodDisruptionBudget`).
    *   Поды перепланируются на новом узле. Старый узел удаляется.
    *   Процесс повторяется для всех узлов.

• Соблюдение PodDisruptionBudget (PDB): PDB — критический инструмент.

  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: my-app-pdb
  spec:
    minAvailable: 2  # Гарантирует, что всегда доступно минимум 2 пода
    # maxUnavailable: 1  # Альтернатива: не более 1 недоступного пода
    selector:
      matchLabels:
        app: my-critical-app
  

    Evict-запрос от `kubectl drain` будет отклонен, если его выполнение нарушит PDB, защищая приложение от неконтролируемого простоя.

• Readiness Probes и PreStop Hooks: Убедитесь, что ваши поды корректно сообщают о своей готовности и имеют preStop hook для graceful shutdown, давая время на завершение активных соединений.

3. Стратегия обновления control plane и управление неизбежным простоем

Если control plane не высокодоступен, его обновление вызовет кратковременный простой API.

• Следование официальной процедуре: Для kubeadm это последовательность команд kubeadm upgrade. В облачных managed-сервисах (EKS, AKS) обновление control plane часто происходит автоматически в выбранное окно.
• Минимизация окна недоступности:

    *   Обновляем в период наименьшей нагрузки.
    *   Временно приостанавливаем автоматические операции (CI/CD пайплайны, автоскейлинг, операторы), которые активно вызывают API.
    *   Информируем мониторинг о плановых работах, чтобы избежать ложных срабатываний.

• План отката: Четко определяем условия и процедуру отката. Например, если через 15 минут после обновления API не отвечает стабильно — восстанавливаем etcd из снапшота.

4. Коммуникация и мониторинг во время окна простоя

• Мониторинг состояния обновления: Используем kubectl get nodes, kubectl get pods, а также внешние health checks для критических эндпоинтов приложений.
• Прозрачность для пользователей: Если внешние сервисы будут недоступны, используем механизмы балансировщиков нагрузки (например, custom error pages в Ingress) для информирования пользователей о техработах.

5. Постверфикация после обновления

После поднятия control plane и обновления всех узлов:

• Проверяем работоспособность всех системных и пользовательских namespace: kubectl get all -A.
• Запускаем smoke-тесты критичных функциональных путей приложений.
• Проверяем логи компонентов (kube-apiserver, kube-controller-manager) на предмет ошибок.
• Убеждаемся, что мониторинг, логирование и сетевая связность работают корректно.

Заключение

Невозможность избежать простоя — не провал, а инженерное ограничение. Ключевая задача — превратить неконтролируемый простой в управляемый и минимальный по времени. Это достигается за счет:

• Исчерпывающего тестирования на не-prod окружениях.
• Стратегического планирования обновления worker nodes с использованием PDB и graceful eviction.
• Четкой коммуникации и подготовленного плана отката.
• Принятия того, что кратковременная недоступность control plane (десятки секунд — несколько минут) в рамках согласованного окна — приемлемая цена за безопасность и стабильность обновления.

В высокодоступных production-средах следует рассмотреть архитектуру с multi-master control plane и обновлением master-узлов по схеме rolling update (например, с использованием kubeadm в HA-конфигурации или возможностей managed-сервисов), что сводит простой API к теоретическому нулю.