Обновление управляемого кластера Managed Kubernetes до версии 1.30: пошаговое руководство для Yandex Cloud, Selectel и VK Cloud

Что нужно знать перед обновлением до Kubernetes 1.30

Обновление управляемого кластера Kubernetes до версии 1.30 требует подготовки. Провайдер отвечает за обновление control plane, вы - за worker-ноды и совместимость приложений. Эта инструкция описывает процесс для Yandex Cloud, Selectel и VK Cloud с учётом их особенностей.

Перед началом работ проверьте, что все ваши манифесты и операторы совместимы с API версии 1.30. Планируйте окно обновления в непиковые часы. Для критичных сервисов используйте стратегию Blue-Green, описанную в нашем руководстве по стратегиям обновления Kubernetes.

Ключевые изменения API в Kubernetes 1.30

Версия 1.30 удаляет несколько устаревших API-ресурсов. Если ваши приложения их используют, обновление вызовет ошибки. Проверьте каждый пункт:

flowcontrol.apiserver.k8s.io/v1beta1 - удалён. Переходите на flowcontrol.apiserver.k8s.io/v1beta3.
networking.k8s.io/v1beta1 Ingress - удалён. Используйте networking.k8s.io/v1 Ingress.
certificates.k8s.io/v1beta1 CertificateSigningRequest - удалён. Переходите на certificates.k8s.io/v1.
autoscaling/v2beta2 HorizontalPodAutoscaler - удалён. Используйте autoscaling/v2.
policy/v1beta1 PodSecurityPolicy - удалён. Мигрируйте на Pod Security Admission.

Полный список изменений доступен в официальном changelog Kubernetes 1.30. Рекомендуем просканировать кластер утилитами kubent или pluto до начала обновления - инструкция по их использованию в разделе «Инструменты для автоматической проверки совместимости».

Общая стратегия обновления managed-кластера

Managed-провайдеры берут на себя обновление control plane (master-узлов). Вы управляете worker-нодами и приложениями. Процесс выглядит так:

Провайдер обновляет control plane до версии 1.30. Это занимает 10-30 минут, API-сервер может быть недоступен короткое время.
Вы обновляете пулы worker-нод. Метод зависит от провайдера: автоматическое обновление или ручное пересоздание.
Вы проверяете совместимость приложений и обновляете манифесты.

Резервное копирование etcd - зона ответственности провайдера. В Yandex Cloud и VK Cloud снимки создаются автоматически. В Selectel уточните детали в панели управления. Если вы управляете кластером через Terraform, подготовьте изменения в коде заранее - примеры для каждого провайдера приведены в соответствующих разделах.

Подготовка приложений к миграции на новые API

Перед обновлением worker-нод убедитесь, что рабочие нагрузки совместимы с Kubernetes 1.30. Пропуск этого шага - основная причина отказов после обновления.

Чек-лист критичных проверок перед обновлением

Проверьте версии клиентских библиотек. Убедитесь, что ваши приложения используют версии client-go, соответствующие Kubernetes 1.30. Минимальная совместимая версия - client-go v0.30.0.
Просканируйте кластер на устаревшие API. Запустите kubent или pluto (команды ниже) и получите список ресурсов, которые перестанут работать.
Обновите Ingress-ресурсы. Если используете Ingress с apiVersion networking.k8s.io/v1beta1, замените на networking.k8s.io/v1. Поле serviceName заменено на service.name, а servicePort - на service.port.number или service.port.name.
Проверьте PodSecurityPolicy. Если использовали PSP, мигрируйте на Pod Security Admission. Создайте политики на уровне namespace через метки pod-security.kubernetes.io/enforce.
Сделайте бэкап критичных данных. Создайте снимки PersistentVolume через Velero или встроенные средства провайдера. Проверьте целостность бэкапов.
Проверьте операторы и контроллеры. Cert-Manager, Ingress-контроллеры, Service Mesh должны быть совместимы с 1.30. Обновите их до актуальных версий.

Инструменты для автоматической проверки совместимости

Три утилиты для быстрой проверки кластера:

kubent (Kube No Trouble). Сканирует кластер и находит ресурсы с устаревшими API. Запуск: kubent --cluster-context production. Вывод показывает namespace, ресурс и версию API, которая будет удалена.
pluto. Проверяет манифесты и Helm-релизы. Запуск для Helm: pluto detect-helm --target-versions k8s=v1.30.0. Для статических манифестов: pluto detect-files -d ./manifests/.
kube-no-trouble. Альтернатива kubent с фокусом на CI/CD. Интегрируется в пайплайны: kube-no-trouble --cluster-context staging.

Пример вывода kubent перед обновлением до 1.30:

NAMESPACE     RESOURCE              VERSION              REPLACEMENT
production    Ingress               networking.k8s.io/v1beta1  networking.k8s.io/v1
monitoring    HorizontalPodAutoscaler autoscaling/v2beta2      autoscaling/v2

Исправьте все предупреждения до обновления control plane.

Планирование окна обновления и минимизация простоев

Обновление control plane занимает 10-30 минут в зависимости от провайдера. В это время API-сервер может быть недоступен для операций записи. Чтение обычно продолжает работать. Worker-ноды обновляются дольше - рассчитывайте 5-10 минут на ноду при автоматическом обновлении, 15-20 минут при ручном пересоздании.

Для кластера из 6 worker-нод полное обновление займёт 1-2 часа с учётом drain/cordon операций. Планируйте окно с запасом 50% на непредвиденные задержки.

Стратегии минимизации простоев:

Rolling update. Worker-ноды обновляются по очереди. Настройте maxSurge и maxUnavailable так, чтобы часть нод всегда обслуживала трафик. Подробнее в руководстве по настройке Rolling Update.
Blue-Green. Создайте новый пул worker-нод с версией 1.30, перенесите нагрузку, удалите старый пул. Подходит для критичных сервисов, описан в статье про стратегии обновления.
Canary. Обновите одну ноду, направьте на неё часть трафика, проверьте стабильность, затем обновляйте остальные.

Оповестите команды за 24 часа до обновления. Укажите точное время начала, ожидаемую длительность и контакты ответственного инженера.

Пошаговое обновление кластера в Yandex Cloud

Yandex Cloud поддерживает автоматическое обновление пулов worker-нод. Вы задаёте процент одновременного обновления, провайдер выполняет drain и пересоздание нод.

Обновление master-узлов через консоль управления

Откройте консоль Yandex Cloud, перейдите в раздел Managed Service for Kubernetes.
Выберите кластер из списка.
На вкладке Обзор нажмите кнопку Обновить версию.
В выпадающем списке выберите версию 1.30.
Подтвердите операцию. Обновление займёт 10-20 минут.

После завершения проверьте версию control plane: kubectl version --short. Серверная часть должна показывать v1.30.x.

Обновление worker-нод: автоматическое и ручное

Автоматическое обновление:

Перейдите в раздел Группы узлов в свойствах кластера.
Выберите группу узлов, нажмите Редактировать.
В поле Версия укажите 1.30.
В блоке Политика обновления задайте Максимальное количество недоступных узлов - например, 1 или 25%.
Сохраните изменения. Yandex Cloud начнёт последовательное обновление нод.

Ручное обновление через новый пул:

Создайте новую группу узлов с версией 1.30 через консоль или CLI.
Выполните kubectl cordon <старая_нода> для каждой ноды старого пула.
Выполните kubectl drain <старая_нода> --ignore-daemonsets --delete-emptydir-data.
Удалите старую группу узлов после переноса всех подов.

Обновление через Terraform (Yandex Cloud)

Пример конфигурации для обновления кластера и группы узлов:

resource "yandex_kubernetes_cluster" "main" {
  name       = "production-cluster"
  master {
    version  = "1.30"
    # остальные параметры master
  }
  # остальные параметры кластера
}

resource "yandex_kubernetes_node_group" "workers" {
  cluster_id = yandex_kubernetes_cluster.main.id
  version    = "1.30"
  instance_template {
    # параметры инстансов
  }
  scale_policy {
    fixed_scale {
      size = 3
    }
  }
  maintenance_policy {
    auto_upgrade = true
    auto_repair  = true
    maintenance_window {
      start_time = "03:00"
      duration   = "3h"
    }
  }
}

Примените изменения: terraform plan, затем terraform apply. Terraform обновит версию кластера и группы узлов.

Пошаговое обновление кластера в Selectel

Selectel не поддерживает автоматическое обновление пулов worker-нод. Обновление выполняется ручным пересозданием нод. Это даёт полный контроль, но требует больше ручных операций.

Обновление control plane в панели Selectel

Войдите в панель управления Selectel, перейдите в раздел Облачная платформа → Managed Kubernetes.
Выберите кластер из списка.
На вкладке Обзор нажмите кнопку Обновить версию.
Выберите версию 1.30 и подтвердите.
Дождитесь завершения - обычно 15-25 минут.

Проверьте статус: kubectl get nodes должен показать control plane версии 1.30.

Ручное обновление worker-нод в Selectel

В панели Selectel создайте новый пул worker-нод с версией 1.30. Укажите нужное количество нод.
Дождитесь, пока новые ноды перейдут в статус Ready: kubectl get nodes -w.
Запретите размещение подов на старых нодах: kubectl cordon <старая_нода> для каждой ноды.
Эвакуируйте поды: kubectl drain <старая_нода> --ignore-daemonsets --delete-emptydir-data --timeout=300s.
Убедитесь, что все поды запущены на новых нодах: kubectl get pods -o wide --all-namespaces.
Удалите старый пул нод через панель Selectel.

Обновление через Terraform (Selectel)

resource "selectel_mks_cluster_v1" "main" {
  name                     = "production-cluster"
  kubernetes_version       = "1.30"
  # остальные параметры
}

resource "selectel_mks_nodegroup_v1" "workers" {
  cluster_id        = selectel_mks_cluster_v1.main.id
  kubernetes_version = "1.30"
  count             = 3
  # параметры нод
}

При изменении версии Terraform пересоздаст группу нод. Убедитесь, что старые ноды выведены из эксплуатации до удаления.

Пошаговое обновление кластера в VK Cloud

VK Cloud поддерживает автоматическое обновление пулов worker-нод с настройкой параметров rolling update. Процесс схож с Yandex Cloud.

Обновление master-узлов в личном кабинете VK Cloud

Войдите в личный кабинет VK Cloud, перейдите в раздел Контейнеры → Кластеры Kubernetes.
Выберите кластер.
На вкладке Версии нажмите Обновить напротив версии 1.30.
Подтвердите операцию. Обновление занимает 15-30 минут.

После завершения версия control plane отобразится на вкладке Обзор.

Обновление worker-нод в VK Cloud

Автоматическое обновление:

В свойствах кластера перейдите в раздел Группы узлов.
Выберите группу, нажмите Редактировать.
Установите версию 1.30.
Настройте параметры обновления: Max Surge (дополнительные ноды при обновлении) и Max Unavailable (максимум недоступных нод).
Сохраните. VK Cloud выполнит rolling update.

Ручное обновление выполняется аналогично Selectel: создайте новый пул, drain старых нод, удалите старый пул.

Обновление через Terraform (VK Cloud)

resource "vkcs_kubernetes_cluster" "main" {
  name    = "production-cluster"
  version = "1.30"
  # остальные параметры
}

resource "vkcs_kubernetes_node_group" "workers" {
  cluster_id = vkcs_kubernetes_cluster.main.id
  version    = "1.30"
  node_count = 3
  # параметры нод
}

Примените изменения через terraform apply. VK Cloud обновит версию кластера и группы узлов.

Проверка успешности обновления и решение типичных проблем

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

Версии нод: kubectl get nodes - все ноды должны показывать версию v1.30.x.
Состояние подов: kubectl get pods --all-namespaces | grep -v Running - поды в статусе Error или CrashLoopBackOff требуют внимания.
Системные поды: kubectl get pods -n kube-system - CoreDNS, kube-proxy должны быть запущены.
Логи control plane: в панели провайдера проверьте логи API-сервера, scheduler, controller-manager на наличие ошибок.
Сетевые политики: проверьте связность между подами в разных namespace.

Диагностика и устранение ошибок после обновления

Ошибка «no matches for kind». Приложение использует удалённый API-ресурс. Проверьте манифест, замените apiVersion на актуальный. Список удалённых API приведён в начале статьи.

Проблемы с сетевыми политиками. После обновления CNI-плагина политики могут перестать работать. Проверьте логи CNI: kubectl logs -n kube-system <cni-pod>. Переустановите политики: kubectl apply -f network-policies/.

Поды в статусе CrashLoopBackOff. Проверьте логи: kubectl logs <pod> --previous. Частая причина - изменение API в конфигурации приложения. Обновите образы контейнеров до версий, совместимых с Kubernetes 1.30.

Ошибки сертификатов. Если кластер долго не обновлялся, сертификаты могли истечь. В managed-кластерах провайдер управляет сертификатами control plane. Для worker-нод проверьте сертификаты kubelet: openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -noout -dates.

Поды не стартуют на новых нодах. Проверьте taints и tolerations: kubectl describe node <нода> | grep Taints. Новые ноды могут иметь taint, который не указан в tolerations подов. Добавьте tolerations или удалите taint: kubectl taint nodes <нода> node.kubernetes.io/unschedulable-.

Для сложных сценариев обновления production-кластеров используйте production-манифесты с настроенными probes и ресурсами - это снижает риск отказов при drain нод.