Как обновить Kubernetes Cluster без простоя

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

Обновление Kubernetes-кластера без простоя — это комплексная задача, требующая тщательного планирования и выполнения пошаговых процедур. Основная цель — обеспечить непрерывность работы приложений во время обновления компонентов управления (control plane) и рабочих узлов (worker nodes). Я применяю стратегию rolling update с использованием как встроенных механизмов Kubernetes, так и дополнительных инструментов для контроля.

Ключевые принципы и подготовка

Перед началом обновления необходимо выполнить несколько критически важных шагов:

• Резервное копирование состояния кластера: Всегда создавайте бэкапы etcd и конфигураций критических ресурсов (например, с помощью etcdctl или Velero).
• Проверка совместимости: Убедитесь, что целевая версия Kubernetes поддерживает ваши версии CNI, CSI, Ingress-контроллеров и других аддонов.
• Чтение release notes: Внимательно изучите заметки о выпуске, особенно разделы про deprecated API и критические изменения.
• Тестирование в staging-среде: Всегда сначала выполняйте обновление в не-продакшен среде.

Поэтапный план обновления (на примере kubeadm)

Для кластеров, развернутых с помощью kubeadm, процесс выглядит следующим образом:

1. Обновление control plane: Мастера обновляются по одному, начиная с не-лидера.
2. Обновление worker nodes: Рабочие узлы дренируются (drain) и обновляются последовательно.

Шаг 1: Обновление kubeadm на первом мастер-узле

# На мастер-узле (например, не являющемся текущим лидером etcd)
apt-get update && apt-get install -y kubeadm=1.28.4-00

Шаг 2: Планирование обновления control plane

kubeadm upgrade plan

Эта команда покажет доступные версии и необходимые действия.

Шаг 3: Применение обновления control plane

kubeadm upgrade apply v1.28.4

Этот шаг обновит статические компоненты Pod'ов control plane на данном узле.

Шаг 4: Обновление kubelet и kubectl на мастере

# Освобождаем узел (на мастере обычно нет рабочих нагрузок, но для чистоты)
kubectl drain <master-node-name> --ignore-daemonsets

# Обновляем kubelet и kubectl
apt-get update && apt-get install -y kubelet=1.28.4-00 kubectl=1.28.4-00

# Перезагружаем kubelet
systemctl daemon-reload
systemctl restart kubelet

# Возвращаем узел в строй
kubectl uncordon <master-node-name>

Повторите шаги 1-4 для каждого мастер-узла в кластере, соблюдая последовательность (сначала не-лидеры etcd).

Шаг 5: Обновление worker nodes (ядро процесса без простоя)

Для каждого рабочего узла выполняем операцию cordon -> drain -> update -> uncordon.

# 1. Запрещаем планирование новых подов на узел
kubectl cordon <worker-node-name>

# 2. Аккуратно вытесняем существующие поды с узла
kubectl drain <worker-node-name> \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --timeout=300s \
  --force

# 3. Обновляем компоненты на узле
ssh <worker-node-name>
sudo apt-get update && sudo apt-get install -y kubeadm=1.28.4-00
sudo kubeadm upgrade node
sudo apt-get install -y kubelet=1.28.4-00 kubectl=1.28.4-00

# 4. Перезапускаем kubelet
sudo systemctl daemon-reload
sudo systemctl restart kubelet

# 5. Разрешаем планирование подов на узле
kubectl uncordon <worker-node-name>

Критически важные аспекты для zero-downtime

• Pod Disruption Budgets (PDB): Самый важный механизм. PDB гарантирует, что во время добровольных вытеснений (как при drain) определенное минимальное количество реплик приложения останется доступным.

  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: my-app-pdb
  spec:
    minAvailable: 2  # Или maxUnavailable: 1
    selector:
      matchLabels:
        app: my-critical-app
  

• Readiness и Liveness Probes: Корректно настроенные пробы гарантируют, что kubelet не завершит старый под до тех пор, пока новый не будет готов принимать трафик.

• Поддержка нескольких версий kubelet: Kubernetes поддерживает разницу в ±1 минорную версию между kubelet на узлах и версией control plane. Это позволяет обновлять узлы постепенно.

• Работа с Stateful-нагрузками: Для stateful-приложений (базы данных) используйте собственные операторы (например, PostgreSQL Operator), которые умеют выполнять rolling update с сохранением данных, или выполняйте обновление вручную с особой осторожностью.

• Обновление аддонов: Такие компоненты как CoreDNS, CNI-плагин, CSI-драйверы часто требуют отдельного, согласованного с версией Kubernetes процесса обновления.

Автоматизация и инструменты

Для управления сложными кластерами я предпочитаю использовать инструменты автоматизации:

• Kubeadm: Для self-hosted кластеров, как показано выше.
• Managed-сервисы (EKS, GKE, AKS): Они предоставляют встроенные механизмы rolling update для worker nodes, что значительно упрощает процесс. Обновление control plane также часто выполняется "в один клик" с минимальным воздействием.
• Terraform + Ansible/Shell-скрипты: Для идемпотентного и контролируемого обновления инфраструктуры и компонентов.
• GitOps-инструменты (ArgoCD, Flux): Позволяют декларативно управлять версиями компонентов кластера (но не самих нод), обеспечивая контролируемый rollout манифестов, совместимых с новой версией API.

Итог: Обновление без простоя — это не одна команда, а процесс, основанный на правильной подготовке, использовании механизмов Kubernetes (PDB, drain/cordon, пробы) и последовательном, поузловом применении изменений. Ключ к успеху — автоматизация рутинных операций и наличие откатного плана на случай непредвиденных проблем.