Kubernetes в проде держат 80% организаций по опросу CNCF за 2024 год, против 66% годом раньше. В России адопшн ниже, но того же порядка: около 60% крупных компаний используют Kubernetes. Спор об управлении кластером в облаке обычно сводится к интерфейсу: консоль или CLI вроде eksctl. Но жизненный цикл кластера всё равно должен кто-то исполнять. Именно здесь и проходит реальная граница между инструментами.

В этой статье мы разбираем пользовательский жизненный цикл кластера второго поколения Managed Kubernetes в VK Cloud: создание, нод-группы, масштабирование, обновление версии и аддоны. За точку сравнения берём eksctl как привычный инструмент управления EKS. Дальше — таблица соответствия задач eksctl операциям VK Cloud, HCL-листинги Terraform-провайдера для кластера, нод-группы и аддона, числовые пороги автоскейлинга мастеров, процедура апгрейда со скрытым control plane и список мест, где обе абстракции дают сбой.

Это статья для инженеров, которые выбирают или эксплуатируют managed Kubernetes в российских облаках и хотят понимать, какие операции берёт на себя платформа. Для платформенных команд, переводящих кластеры в IaC. Если у вас самосборный Kubernetes, разделы об апгрейдах и запасе узлов тоже пригодятся: они описывают механику самого Kubernetes.

Эталон одной команды

README проекта eksctl обещает: «Вы можете создать кластер за несколько минут, выполнив всего одну команду», и это обещание честное. Утилита сама создаст VPC, control plane и две ноды m5.large по умолчанию, а kubeconfig положит в ~/.kube/config. За кулисами работает CloudFormation, механизм стеков AWS. В репозитории это сказано прямо: eksctl написан на Go и использует CloudFormation.

За несколько лет вокруг этой команды вырос целый жанр. На Хабре по ней собирали мегагайды на 66 тысяч знаков, а Сергей Полунин из «Газинформсервиса» в разборе 2022 года советовал использовать консольные утилиты при первом развёртывании EKS. CLI стал входной точкой в managed Kubernetes для тех, кому консоль казалась слишком медленной.

Из привычной картины выпадает статус самого проекта. Во-первых, eksctl никогда не был проектом CNCF. Его создала компания Weaveworks; проект следует CNCF Code of Conduct, но в реестрах фонда не значится. Сейчас репозиторий ведёт AWS под названием «The official CLI for Amazon EKS». Во-вторых, документация переехала с eksctl.io в AWS Docs, а старый домен теперь перенаправляет на неё.

Утилита давно переросла набор флагов. Основной сценарий выглядит как декларативный YAML: ClusterConfig со схемой eksctl.io/v1alpha5, в котором описаны metadata, vpc, nodeGroups, а поверх него работают команды create, upgrade и delete. В релизах 2026 года появился даже откат версии кластера через rollbackConfig. Эталон жанра выглядит так: декларативный конфиг, императивные команды и внешний механизм стеков под капотом.

Тот же цикл в VK Cloud

В VK Cloud кластеры Kubernetes существуют в двух поколениях. Первое работает на Magnum, инструменте оркестрации контейнеров из OpenStack. Кластер целиком живёт в проекте пользователя вместе с системными компонентами, и пользователь сам отвечает за их состояние.

Второе поколение управляемых кластеров сервис выпустил в конце 2025 года. Модель устроена иначе: мастер-ноды, диски, постоянные тома и сервисные балансировщики вынесены в сервисные проекты — изолированную среду на стороне платформы. Пользовательский кластер запускается внутри системного кластера. В мастере создания это поколение обозначено опцией «Новое поколение».

Автор статьи VK Tech об архитектуре Gatekeeper, ведущий разработчик команды, описывает модель так: «вы остаетесь администратором внутри своего кластера… но инфраструктура, control plane и системные компоненты полностью управляются провайдером и скрыты от глаз пользователя».

Для пользователя eksctl здесь одновременно много знакомого и нового. В EKS control plane тоже скрыт, но воркеры остаются вашими EC2-инстансами в вашем аккаунте. Во втором поколении VK Cloud платформа управляет и воркерами. У вас остаются сетевая связность с ними и полный доступ к Kubernetes API, а слой виртуальных машин выходит из зоны ответственности.

Сервисный проект — это проект-невидимка рядом с вашим. Платформа размещает там ВМ узлов, их диски и балансировщик API. В документации есть прямое предупреждение: любые действия с портами этих ресурсов могут привести к нестабильной работе кластера. Граница ответственности проходит буквально по списку ресурсов в интерфейсе.

Создание кластера

Через личный кабинет кластер второго поколения создаётся мастером: выбираются версия Kubernetes, тип кластера, сеть, CNI и группы узлов. Тип определяет топологию control plane. Стандартный кластер использует 1, 3 или 5 мастер-нод в одной зоне доступности, отказоустойчивый распределяет 3 или 5 мастеров между тремя зонами.

Платформа сама выбирает флейвор мастеров. По умолчанию это 2 CPU, 8 ГБ RAM и системный SSD-диск на 20 ГБ. Для каждого экземпляра etcd выделяется отдельный высокопроизводительный SSD класса High-IOPS. Из компонентов мастера именно etcd особенно чувствителен к задержкам диска.

Kubeconfig скачивается автоматически после создания. Документация обещает создание за 5–20 минут, а автор мегагайда по EKS называл для eksctl 10–15 минут. Порядок времени сопоставим.

Терминальный путь здесь предлагает Terraform. Полный кластер описывается ресурсом vkcs_kubernetes_cluster_v2:

resource "vkcs_kubernetes_cluster_v2" "k8s_cluster" {
  name    = "k8s-standard-cluster"
  version = "v1.35.6"

  cluster_type       = "standard"
  master_count       = 1
  availability_zones = ["MS1"]
  master_flavor      = data.vkcs_compute_flavor.master.id

  network_id             = vkcs_networking_network.app.id
  subnet_id              = vkcs_networking_subnet.app.id
  loadbalancer_subnet_id = vkcs_networking_subnet.app.id
  network_plugin         = "calico"
  pods_ipv4_cidr         = "10.100.0.0/16"
}

resource "vkcs_kubernetes_node_group_v2" "default" {
  cluster_id             = vkcs_kubernetes_cluster_v2.k8s_cluster.id
  name                   = "k8s-node-group"
  node_flavor            = data.vkcs_compute_flavor.worker.id
  availability_zone      = "MS1"
  scale_type             = "fixed_scale"
  fixed_scale_node_count = 3
  parallel_upgrade_chunk = 40 # процент недоступных нод при обновлении
  disk_type              = "ceph-ssd"
  disk_size              = 20
}

Сходство с ClusterConfig от eksctl прямое: та же декларативная запись того, каким должен быть кластер, и те же нод-группы отдельными блоками. Различается исполнитель. eksctl разворачивает YAML в стеки CloudFormation: вы запускаете команду, CloudFormation исполняет стеки на стороне AWS, а следить за дрейфом и повторять прогон приходится вам. Terraform-провайдер VK Cloud передаёт желаемое состояние оркестратору облака. Затем платформа непрерывно приводит кластер к этому состоянию.

Экспортируемые атрибуты закрывают бытовые задачи: kubeconfig доступен в поле k8s_config, API-эндпоинт — в api_address, а доступ к API можно ограничить списком CIDR через loadbalancer_allowed_cidrs.

Задачи eksctl и их эквиваленты

В таблице слева — команды из документации eksctl, справа — способы решить ту же задачу в VK Cloud.

Единственную нод-группу кластера нельзя удалить через личный кабинет, хотя Terraform это ограничение обходит. Drain в VK Cloud вообще не оформлен как пользовательская команда. Поды вытесняются внутри процедур платформы при обновлении и масштабировании.

У eksctl вокруг drain больше сервисных возможностей. Есть команда drain nodegroup --undo, которая возвращает ноды в строй, и glob-фильтры вроде --include='ng-prod-*' для операций сразу над несколькими группами.

Группы узлов настраиваются одним набором параметров и в личном кабинете, и в Terraform: флейвор, зона доступности, тип и размер диска, количество узлов, границы автоскейлинга, метки и тейнты. Для production-нагрузок документация рекомендует SSD-диски и минимум две ноды в группе. Отказоустойчивую конфигурацию собирают из нескольких групп в разных зонах доступности, а реплики приложений распределяют между ними через topology-ограничения.

Смена флейвора существующей группы не требует пересоздания. Terraform-ресурс запускает rolling upgrade: ноды переходят на новый флейвор волнами. Шаблоны с высокопроизводительными CPU открываются через поддержку.

Аддоны

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

В каталоге второго поколения доступны Argo CD, ingress-nginx, cert-manager, kube-prometheus-stack, Istio, external-secrets-operator, s3-csi и другие. Они работают на воркер-узлах и потребляют их ресурсы, поэтому для тяжёлого набора аддонов документация рекомендует выделить отдельную нод-группу с автоскейлингом.

В коде аддон описывается ресурсом vkcs_kubernetes_cluster_addon_v2:

resource "vkcs_kubernetes_cluster_addon_v2" "ingress" {
  cluster_id       = vkcs_kubernetes_cluster_v2.k8s_cluster.id
  addon_id         = data.vkcs_kubernetes_addon_v2.ingress.addon_id
  addon_version_id = data.vkcs_kubernetes_addon_v2.ingress.id
  addon_name       = "ingress-nginx"
  namespace        = "ingress-nginx"
  values           = data.vkcs_kubernetes_addon_v2.ingress.values_template
}

В листинге показан только каркас. Конфигурация аддона передаётся в values как YAML, а доступный набор зависит от региона. У eksctl аналогичную роль играет команда create addon с политиками IAM. GitOps в обеих моделях вынесен в отдельный контур: eksctl вызывает flux bootstrap, а VK Cloud устанавливает Argo CD как аддон из того же каталога.

Разворачивайте кластеры Kubernetes с Managed Containers

Автоматизируйте деплой
и снижайте затраты на инфраструктуру
до 60%

Попробовать

В итоге контур управления во втором поколении замыкается на четырёх участниках: интерфейсе, API сервиса, оркестраторе и системном кластере, внутри которого работает пользовательский кластер.

Жизненный цикл в обеих моделях описывается декларативно. У eksctl желаемое состояние воплощает разовый запуск команды: CloudFormation исполняет стеки, а наблюдение за дрейфом остаётся на пользователе. В VK Cloud состояние принимает оркестратор платформы, а облако непрерывно приводит к нему кластер. kubectl в обеих моделях остаётся у пользователя, control plane скрыт в обеих, но во втором поколении VK Cloud под управление платформы уходят и воркеры. 

Масштабирование и апгрейд

Автоскейл воркеров

Cluster Autoscaler предустановлен в каждом кластере, но по умолчанию выключен. Его включают для конкретной группы узлов и там же задают минимальное и максимальное число нод. В одной группе может быть до 500 воркер-нод. Пока автоскейлинг включён, вручную менять число узлов нельзя: сначала его нужно отключить в настройках группы.

Механика соответствует upstream Cluster Autoscaler. Расширение запускает под в состоянии Pending, которому не хватает ресурсов по requests. Планировщик учитывает resources.requests, а не limits, поэтому кластер с завышенными запросами будет расти раньше, чем ожидает команда.

Сжатие работает осторожнее: платформа вытесняет поды с недозагруженной ноды, ждёт пять минут простоя, помечает ноду тейнтом и удаляет её. По оценке VK Cloud, автоскейлинг способен экономить до 60% вычислительных ресурсов. Цифра вендорская, но её направление согласуется с мировой статистикой недозагрузки контейнерных нагрузок.

Автоскейл мастеров

Дальше начинается механика, которой в мире eksctl нет. Мастер-ноды второго поколения масштабируются вертикально автоматически. Автоматика включена всегда и не отключается.

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

• CPU выше 80% в течение минуты;

• CPU выше 60% в течение пяти минут;

• RAM выше 90% в течение минуты.

При срабатывании по CPU мастер получает два дополнительных ядра. При срабатывании по памяти RAM увеличивается по шкале 6, 8, 12, 16, 20, 24, 32, 36 и 48 ГБ. Вниз автоматика не масштабирует мастер-ноды. Уменьшить флейвор можно только вручную.

В EKS control plane также обслуживает провайдер, но подробности его масштабирования наружу не выведены: нет ни порогов, ни шкалы, ни ручного управления. В VK Cloud мастера тоже скрыты, но правила их роста опубликованы. Чёрный ящик здесь идёт с паспортом: известны пороги и шаги масштабирования.

У автоматики есть финансовая и техническая цена. Master- и worker-узлы тарифицируются одинаково: по ядрам, памяти и дискам, с отдельной детализацией расходов по мастерам. Невозможность отключить рост control plane означает, что за расходами нужно следить.

С технической стороны смена флейвора поочерёдно перезапускает виртуальные машины. В кластере с одним мастером Kubernetes API на время операции становится недоступным, а нагрузка в группе с единственным воркером простаивает. Это ещё один аргумент в пользу минимум трёх мастер-нод и групп из двух и более воркеров.

События масштабирования можно отправлять в алертинг. Для этого предусмотрены триггеры kubernetes_master_vscale и kubernetes_worker_hscale.

Обновление версии

Политики версий у платформ удивительно похожи. VK Cloud поддерживает версию 14 месяцев с даты её появления в сервисе и за 30 дней до завершения поддержки отправляет письмо и уведомление в личный кабинет.

Между релизом upstream Kubernetes и появлением версии в сервисе проходит от пяти до восьми месяцев. Например, ветка 1.33 вышла 15.05.2025, появилась в сервисе 20.10.2025 и завершит поддержку 20.12.2026 — через 14 месяцев после появления в VK Cloud.

Сейчас в сервисе доступны 1.35.6, 1.34.2 и 1.33.3. Формально в списке остаются 1.32.1 и 1.31.4, но их поддержка уже закончилась: 28.07.2026 и 17.04.2026 соответственно. В ближайшее время в сервисе останутся три ветки, начиная с 1.33.

У EKS standard support также длится 14 месяцев, после чего доступна платная extended support ещё на год. На обеих платформах обновление выполняется только на одну минорную версию за шаг и только вперёд.

В VK Cloud используется одна стратегия — обновление на месте, in-place. AWS в гайде по обновлениям EKS рекомендует тот же подход как основной. Blue-green с двумя параллельными кластерами оставляют для перехода через несколько версий: два кластера стоят дороже, а кроме того, меняются API-эндпоинт и OIDC.

Полезно помнить о допустимом рассинхроне версий в Kubernetes. Начиная с 1.28 kubelet может отставать от control plane на три минорные версии, поэтому воркеры не обязаны догонять мастера в день обновления. В EKS managed node groups вообще наследуют версию control plane: флаг --version для них не поддерживается.

Процедура в VK Cloud описана в концепциях. Сначала обновляются мастера, строго по одному: нода выходит из кластера, обновляется, проходит проверку и возвращается в строй. Затем обновляются группы воркеров — уже пачками. Размер пачки задаёт параметр «Процент недоступных нод при обновлении кластера», которому в Terraform соответствует parallel_upgrade_chunk.

Документация приводит расчёт: если в группе девять нод, а нагрузке достаточно шести, можно обновлять по три ноды одновременно. Для этого нужно установить значение 33%.

Перед обновлением стоит помнить о трёх свойствах процедуры:

• Во время обновления не работает автоскейлинг, поэтому узлы для переезжающей нагрузки нужно добавить заранее вручную.

• Вместе с кластером обновляются Gatekeeper, встроенный компонент платформы, а не ваш OPA Gatekeeper, Shell Operator и CoreDNS. Corefile при этом заменяется конфигурацией по умолчанию. Кастомный Corefile без резервной копии будет потерян.

• Аддоны вместе с кластером не обновляются: их версии команда меняет самостоятельно.

Перед обновлением инструкция предлагает полный прогон: создать резервную копию через Velero, развернуть из неё копию кластера, отрепетировать обновление и только затем переходить к боевому окружению. Это дороже, чем сценарий «eksctl upgrade cluster и посмотрим», но после репетиции остаётся гораздо меньше сюрпризов.

Тот же порядок — release notes, бэкап, control plane, аддоны и data plane — AWS рекомендует в best practices по апгрейдам EKS. Методика у платформ одна, но VK Cloud выполняет больше шагов самостоятельно.

Автоскейл воркеров включается для конкретной группы и ориентируется на requests, а мастера автоматически растут по опубликованным порогам. Апгрейд идёт волной: мастера по одному, воркеры — пачками, размер которых определяется процентом недоступных нод. Запас узлов и бэкап Corefile нужно подготовить до начала обновления, потому что автоскейлинг во время него отключён.

Где протечки у абстракции

У eksctl протечки задокументированы давно. Команда delete cluster без флага --wait только отправляет запрос на удаление стека и не ждёт завершения. Если удаление зависло, документация предлагает открыть консоль CloudFormation и вручную очистить стеки.

Там же есть флаг --disable-nodegroup-eviction, который позволяет обойти PodDisruptionBudget, если drain упёрся в него. Абстракция «одна команда» заканчивается в момент, когда стек CloudFormation оказывается в ошибочном состоянии.

В VK Cloud протечки другие, но они также описаны в документации. Главная находится на стыке интерфейсов: личный кабинет и Terraform не знают друг о друге. Изменения, сделанные в ЛК, не попадают в tfstate. Следующий terraform apply откатит их и, как предупреждает документация, в худшем случае может привести «к неработоспособности кластера».

Штатное лечение — terraform apply -refresh-only и актуализация конфигурации. Но важнее организационная мера: кластер нельзя менять мимо кода, если Terraform считается источником истины.

Вторая протечка тоньше. Метки и тейнты, заданные через платформу, синхронизируются в кластер в одну сторону и перезаписывают одноимённые ключи, добавленные через kubectl. Метки и тейнты, добавленные мимо платформы, продолжают работать, но не видны ни в личном кабинете, ни в tfstate.

К этой же группе относится перезапись Corefile при обновлении: кастомная конфигурация заменяется настройками по умолчанию, и восстановить её можно только из заранее подготовленного бэкапа.

Критики managed-подхода назовут это платой за чужой control plane. Плата есть, но в двух моделях счёт приходит в разных местах. Протечка eksctl обычно означает разовую ручную очистку стека CloudFormation после собственной команды. Рассинхронизация личного кабинета и tfstate опаснее: изменить кластер может человек, который не знает о существовании Terraform, а ошибка проявится на следующем apply и затронет весь кластер.

Проблема решается не документацией, а внутренним правилом: не менять кластер вне IaC-контура. При этом и AWS, и VK Cloud описывают острые углы в официальной документации, что позволяет подготовиться до инцидента.

Границы контура

Отката версии кластера нет: понижение запрещено политикой обновления. Роль eksctl в VK Cloud распределена между личным кабинетом, Terraform-провайдером и kubectl.

Ограничение по CNI, из-за которого Cilium ещё недавно можно было включить только через личный кабинет, снято. Теперь network_plugin в Terraform-ресурсе v2 принимает и calico, и cilium: поддержку добавили в провайдере 0.17.1.

За рамками статьи остаются две темы: миграция существующих кластеров первого поколения на Magnum в новую модель и прямое сравнение с managed-сервисами других российских облаков. Обе заслуживают отдельного разбора; eksctl здесь нужен только как знакомая многим точка отсчёта.

Открытые замеры

Публичную планку скорости автоскейлинга задал Флант: 40 секунд на ввод новой ноды в связке EKS, Karpenter и spot-инстансов. Для VK Cloud такой замер можно снять той же методикой: создать под с requests, превышающими свободные ресурсы, и измерить время от Pending до Running на новой ноде. Повторите тест в своём окружении — результаты будет интересно сопоставить.

Ещё одна полезная цифра относится к автоскейлингу в целом. По Datadog Container Report за 2023 год, более 65% контейнерных нагрузок используют меньше половины запрошенных CPU и памяти, а HPA применяет лишь половина организаций. Автоскейлер масштабирует то, что указано в запросах ресурсов. Если requests завышены вдвое, кластер также будет вдвое больше необходимого, и Cluster Autoscaler этого не исправит.

Куда движется управление кластерами

Kubernetes-сообщество уже сформулировало направление. Cluster API, сабпроект SIG Cluster Lifecycle, описывает создание, масштабирование, обновление и удаление кластеров через декларативные API. Кластер становится объектом reconciliation так же, как Deployment.

eksctl движется в ту же сторону. Команда enable flux вызывает flux bootstrap, передавая доставку приложений отдельному GitOps-инструменту. По опросу CNCF, GitOps-практики используют 77% респондентов. Для большинства команд доставка приложений уже живёт в отдельном декларативном контуре рядом с кластером.

eksctl, Cluster API и оркестратор второго поколения VK Cloud сходятся в одной точке: желаемое состояние описывается декларативно, а затем его поддерживает контур reconciliation. Различается только владелец этого контура: разовый запуск команды, оператор в вашем кластере или оркестратор облачного провайдера.

Версии и ссылки

Всё описанное проверяется по открытым источникам; состояние — на сентябрь 2026 года. В VK Cloud поддерживаются Kubernetes 1.35.6, 1.34.2 и 1.33.3, там же опубликованы даты релизов и окончания поддержки. Дистрибутив сертифицирован CNCF в рамках программы Certified Kubernetes для hosted-платформ.

Стартовые точки для повторения: документация Cloud Containers, репозиторий terraform-provider-vkcs с ресурсами kubernetes_cluster_v2, kubernetes_node_group_v2 и kubernetes_cluster_addon_v2, а также документация eksctl в AWS Docs для сравнения с эталоном.

HCL-фрагмент из раздела о создании кластера самодостаточен: остаётся добавить сеть и data source флейворов.

Managed Kubernetes постепенно убирает из повседневной работы операции с мастер-нодами и виртуальными машинами. Во втором поколении VK Cloud control plane и инфраструктура мастеров находятся в сервисном проекте платформы, а пользователь управляет кластером через Kubernetes API, личный кабинет и Terraform. Главный вопрос здесь не в выборе интерфейса, а в том, какие части жизненного цикла берёт на себя облако и где заканчивается его зона ответственности.