Обновление кластера
Тема дорожной карты · Kubernetes
Обновление кластера Kubernetes — это процесс перехода K8s-кластера на более новую минорную или патч-версию, требующий тщательного соблюдения последовательности для сохранения доступности рабочих нагрузок и совместимости API. Стандартный путь обновления предполагает сначала обновление плоскости управления — kube-apiserver, kube-controller-manager и kube-scheduler — прежде чем переходить к рабочим узлам, поскольку Kubernetes гарантирует допустимое расхождение версий n-1 между плоскостью управления и kubelet. Для кластеров под управлением kubeadm процесс начинается с команды kubeadm upgrade plan для просмотра доступных версий, затем следует kubeadm upgrade apply v<version> на узле плоскости управления и kubectl drain с последующим kubeadm upgrade node на каждом рабочем узле. Управляемые сервисы Kubernetes — EKS, GKE и AKS — предлагают автоматизированные каналы обновления, тогда как при самостоятельном управлении кластерами необходимо также обновлять CNI-плагин, CSI-драйверы и admission-вебхуки, API-версии которых могут быть устаревшими или удалёнными в новом релизе K8s.
Как это работает
Обновление кластера покрывает day-2 работу эксплуатации Kubernetes-кластера: обновления, node maintenance, capacity planning, backup и DR, оптимизация стоимости, multi-tenancy изоляция. Обновления следуют графику deprecation Kubernetes (один minor каждые 4 месяца); node maintenance использует cordon + drain; backups через Velero или CSI snapshots. DR требует регулярных тренировок — не только документации.
Когда применять
Установите Обновление кластера практики до того, как кластер станет критичным для выручки. Запланируйте первую DR-тренировку в течение 30 дней после go-live; задокументируйте процедуру обновления до того, как первая версия станет EOL; настройте cost-дашборды (Kubecost, OpenCost) до того, как счёт станет сюрпризом. Operations-долг копится тихо — гасите его по каденции, не в режиме паники.
Типичные ошибки
Ловушки cluster operations: пропуск minor-обновлений до принуждения (3+ версий позади = кошмар обновления); cluster-wide cluster-admin tokens, которые никто не ротирует; нет задокументированного runbook на случай "control plane умер" (реальная возможность на self-managed кластерах); cost-сюрпризы (idle GPU-ноды, over-provisioned requests, orphan PVCs). Тренируйте incident response на non-production кластере ежемесячно.