Был ли у вас опыт обновления кластера Kubernetes?

Да, я выполнял обновления production-кластеров Kubernetes, как self-hosted (на базе kubeadm), так и managed (EKS, GKE). Процесс требует тщательного планирования.

Мой типичный план для kubeadm-кластера:

1. Подготовка и проверка:

   • Изучаю release notes целевой версии на предмет критических изменений и deprecated API.
   • Проверяю совместимость версий control plane и компонентов (kubelet, kubectl).
   • Выполняю полное резервное копирование etcd: etcdctl snapshot save snapshot.db.
   • Использую kubectl get all --all-namespaces -o yaml > cluster-backup.yaml для резервирования ресурсов.

2. Обновление control-plane нод (последовательно, одна за другой):

   # На первой master-ноде
   kubeadm upgrade plan
   kubeadm upgrade apply v1.28.4
   # Обновляем kubelet и kubectl на этой ноде
   apt-get update && apt-get install -y kubelet=1.28.4-00 kubectl=1.28.4-00
   systemctl daemon-reload
   systemctl restart kubelet

   Повторяю для остальных master-нод.

3. Обновление worker-нод (по одной, с drain):

   # Подготавливаем ноду к обновлению
   kubectl drain <worker-node-name> --ignore-daemonsets --delete-emptydir-data --timeout=300s
   
   # На самой worker-ноде
   kubeadm upgrade node
   apt-get update && apt-get install -y kubelet=1.28.4-00
   systemctl daemon-reload
   systemctl restart kubelet
   
   # Возвращаем ноду в работу
   kubectl uncordon <worker-node-name>

4. Верификация: После обновления всех нод проверяю состояние кластера (kubectl get nodes), работу критичных подов и дашборды мониторинга. Особое внимание уделяю workloads, использующим deprecated API — их нужно модифицировать до обновления.

Для managed-сервисов процесс проще (например, в EKS выбирается новая версия и запускается managed update нод-групп), но требует контроля за графиком и тестирования.