Как спланировать upgrade control plane и узлов крупного production-кластера Kubernetes с минимальным риском простоя, и какие здесь компромиссы?

Короткий ответ

Единого безопасного пути нет: upgrade обычно выполняют поэтапно — сначала control plane (с учётом version skew policy, допускающей control plane не более чем на несколько минорных версий новее kubelet), затем узлы партиями с drain и PodDisruptionBudget, предварительно проверив совместимость API-версий используемых манифестов и операторов в тестовом окружении — конкретная стратегия зависит от допустимого окна обслуживания, критичности workload и зрелости CI/CD для инфраструктуры.

Как это работает подробнее

Kubernetes поддерживает ограниченный version skew между компонентами (control plane может быть новее kubelet на worker-узлах на определённое число минорных версий, точное значение зависит от версии проекта), поэтому апгрейд должен идти в определённом порядке и нельзя пропускать несколько минорных версий сразу без промежуточных шагов, если это не поддерживается явно. Managed-кластеры (EKS/GKE/AKS) частично автоматизируют control plane upgrade, но ответственность за совместимость workload (устаревшие apiVersion, снятые с поддержки в новой версии API) остаётся на команде.

• Компромисс. более частые, мелкие апгрейды (например, каждую минорную версию) снижают риск каждого отдельного шага, но увеличивают операционную нагрузку на команду; редкие большие скачки версий проще спланировать по времени, но риск несовместимости и объём необходимого тестирования в каждом таком апгрейде выше. Выбор зависит от размера платформенной команды, количества и разнородности workload в кластере, и от того, насколько критичен простой для бизнеса в конкретном окне обслуживания — обсуждение этих факторов с заинтересованными сторонами должно предшествовать выбору конкретного расписания апгрейдов.

Пример кода

Команды и выводКопировать

kubectl get deployments -A -o json | pluto detect -o wide -

Что использовать на практике

• Практика. перед апгрейдом нужно проверить kubectl deprecations/сторонние инструменты (например, kubent/pluto) на использование удаляемых API-версий, протестировать апгрейд на некритичном окружении, обновлять узлы постепенно партиями (node pool за node pool) с PDB и drain, следя за метриками ошибок и латентности между партиями, и иметь чёткий план отката (для managed control plane откат может быть невозможен, тогда план отката — это откат на уровне workload/конфигурации, а не самого control plane).

Подводные камни

• Риски. частая ошибка — пытаться перескочить через несколько минорных версий kubelet за один шаг, нарушая version skew policy, или не проверить устаревшие apiVersion в манифестах перед апгрейдом control plane, из-за чего объекты перестают приниматься после обновления.