Кластеры второго поколения в Managed Kubernetes от VK Cloud: что берёт на себя платформа

Managed Kubernetes от VK Cloud по-разному распределяет работу с кластером между платформой и командой. Само слово «управляемый» ничего не говорит о том, сколько обязанностей остаётся у пользователя: в сервисе есть два поколения кластеров, и различие между ними определяется местонахождением системных компонентов.

В кластерах первого поколения все компоненты размещаются в пользовательском проекте, включая системные. Во втором поколении системный слой вынесен в сервисный проект VK Cloud, и это меняет границу ответственности. Команда по-прежнему отвечает за приложения и данные, а системную инфраструктуру обслуживает VK Cloud. В документации этот сервис пока называется Cloud Containers, и по этому названию можно найти разделы о кластерах второго поколения, их архитектуре и доступных функциях.

Два поколения — две модели ответственности

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

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

Развёртывание и автоматическое масштабирование кластеров первого поколения автоматизирует Magnum — инструмент OpenStack для оркестрации контейнеров.

Кластеры размещаются в пользовательских проектах. Пользователь получает доступ ко всем компонентам кластера, включая системные.

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

Второе поколение: изоляция системного слоя

Компоненты кластеров второго поколения находятся в сервисных проектах. Сервисный проект — изолированная среда, в которой пользователю недоступно управление системными компонентами кластера.

Для каждого кластера второго поколения в сервисном проекте создаются master-узлы, на которых запускается системный кластер. Пользовательский кластер разворачивается внутри этого системного кластера и подключается по сети к пользовательскому проекту.

Ресурсы распределяются между проектами так:

• В сервисном проекте находятся виртуальные машины, диски ВМ, постоянные тома, сервисные балансировщики для доступа к Kubernetes API и их IP-адреса.
• В пользовательском проекте остаются порты, стандартные балансировщики нагрузки и их IP-адреса.

Снаружи кластер второго поколения остаётся обычным Kubernetes-кластером: работают kubectl и Kubernetes API. Terraform в этот список не входит. Документация VK Cloud относит управление через Terraform только к кластерам первого поколения и повторяет это ограничение в нескольких разделах.

Это первое заметное ограничение при переходе. Остальные различия собраны в таблице ниже.

Что VK Cloud берёт на себя во втором поколении

Сопровождение системного слоя

VK Cloud управляет системными компонентами кластеров второго поколения, а также их master- и worker-узлами. Преимущества второго поколения:

• автоматизированная настройка и сопровождение инфраструктуры;
• высокая доступность;
• отказоустойчивость;
• производительность;
• надёжность кластеров.

Границы ответственности таковы:

• Версию кластера обновляет пользователь через личный кабинет.
• Аддоны не обновляются вместе с кластером, их обновляет пользователь.
• Конфигурацию master-узлов платформа выбирает автоматически.
• По умолчанию master-узел получает 2 CPU, 6 ГБ оперативной памяти и диск High-IOPS SSD на 20 ГБ.
• Автомасштабирование master-узлов включено и не отключается.

Кластер сохраняет работоспособность, пока доступно более половины master-узлов. Топология из трёх или пяти узлов с распределением по зонам доступности повышает устойчивость к сбоям, но не означает стопроцентную доступность.

Защита от случайных изменений системного слоя

Изоляция сервисного проекта закрывает доступ к системным компонентам, но не защищает кластер от всех ошибок.

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

Для каждого кластера создаются три группы правил безопасности с суффиксами -base, -master и -minion. Их изменение также может привести к неработоспособности кластера.

Разграничение ответственности описано и в разделе о CIS-бенчмарке: платформа обеспечивает защиту master-узлов, а пользовательские настройки кластера остаются в зоне ответственности команды.

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

Встроенный мониторинг и политика аудита

Для кластеров второго поколения включена интеграция с сервисом мониторинга VK Cloud. Отключить её нельзя, а сам мониторинг не тарифицируется.

Политика аудита также преднастроена: события Kubernetes API записываются в Cloud Audit, изменить эту политику нельзя. Для задач комплаенса это упрощает сбор журналов, но командам со своей политикой аудита придётся учитывать ограничение.

Встроенный мониторинг не заменяет собственный стек метрик. Аддон Kube Prometheus Stack устанавливает и обновляет пользователь. Ограничений по поколениям для него документация не указывает.

Платформа берёт на себя базовую наблюдаемость и журнал аудита, но сбор прикладных метрик, настройка алертов и поддержка собственного Prometheus-стека остаются задачами команды.

Управление томами и дисками

Управлять созданными постоянными томами через личный кабинет VK Cloud можно только в кластерах второго поколения: Кластеры Kubernetes → Диски PV.

Тома находятся в сервисном проекте, которым управляет платформа. Если кластер нужно удалить или перенести, PV можно переместить из сервисного проекта в пользовательский, чтобы сохранить доступ к данным.

У переноса есть два ограничения:

• Переместить или удалить PV можно только после отвязки от группы узлов.
• После переноса вернуть PV из пользовательского проекта в сервисный нельзя.

Постоянные тома тарифицируются только для кластеров второго поколения.

Сравнение поколений

Второе поколение — не прямой апгрейд первого, а другая модель работы. Оно добавляет Cilium, мультизональные классы хранения, управление PV через личный кабинет и пять аддонов, которых нет в первом поколении. Взамен недоступны Terraform, Kubernetes Dashboard и четыре аддона первого поколения.

Сертификат Certified Kubernetes — Hosted от CNCF документация относит к дистрибутиву Kubernetes от VK Cloud в целом, без разбивки по поколениям. Доступность аддонов также зависит от региона, в котором развёрнут кластер.

Как планировать миграцию на второе поколение

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

Инвентаризация

Проверять нужно не только список Deployment, но и совместимость API.

Опрос API-сервера не всегда поможет: объект, созданный как deployments.v1beta1.extensions, API может вернуть уже в виде apps/v1. Устаревшие apiVersion нужно искать в репозиториях с манифестами и в Helm-релизах. Для этого можно использовать, например, Pluto.

В инвентаризацию также стоит включить:

• аддоны, которых нет во втором поколении;
• stateful-сервисы;
• внешние интеграции;
• секреты;
• скрипты и CI/CD-пайплайны, привязанные к конкретному кластеру;
• DNS-записи и балансировщики;
• внешние системы аутентификации, мониторинга и журналирования.

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

Новый кластер рядом

Для создания кластера второго поколения в проекте должна быть подключена SDN Sprut. Если она не подключена, нужно обратиться в техническую поддержку.

Если приложения разворачиваются через Argo CD, целевой кластер задаётся полем spec.destination. В этом случае запуск окружения рядом сводится к смене destination для нужного приложения.

Арго CD доступен только в кластерах второго поколения. В первом поколении такого аддона нет.

Git не перенесёт автоматически:

• секреты;
• намеренно императивные поля, например replicas, которыми управляет HPA;
• данные в постоянных томах;
• DNS-записи;
• балансировщики;
• внешние интеграции.

Эти объекты либо не хранятся в репозитории с манифестами, либо требуют отдельной подготовки на целевом кластере. Секреты можно создавать через Sealed Secrets, External Secrets Operator или Secrets Store CSI Driver.

Перенос stateless-нагрузки

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

Это сравнительно простая часть миграции. Она помогает обнаружить недостающие зависимости: всё, что не переехало с первого прохода, нужно добавить в план.

Перенос данных

Аддон Velero доступен только во втором поколении, но не поддерживает резервное копирование постоянных томов.

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

Для баз данных нужно отдельно оценить каждый путь миграции. Бэкап кластера в Velero не атомарен, а File System Backup читает работающую файловую систему и не гарантирует единую точку во времени.

Для СУБД проект Velero рекомендует pre- и post-хуки, которые помогают зафиксировать согласованное состояние на время создания копии.

Логическая репликация PostgreSQL сокращает простой, но не переносит:

• схему и DDL;
• значения последовательностей;
• large objects.

После переключения значения последовательностей нужно обновить отдельно. Иначе первая же вставка может завершиться конфликтом ключей.

Переключение трафика и вывод старого кластера

Перед удалением старого кластера переведите критичные тома на политику освобождения Retain.

Динамически созданные тома наследуют политику класса хранения. По умолчанию это Delete: при удалении PV удаляется и облачный диск. Политика Retain сохраняет том и данные, но PV получает статус Released.

Трафик лучше переключать через балансировщик. DNS стоит использовать как дополнительный механизм, а не как единственный способ переключения: часть резолверов может хранить записи дольше указанного TTL. Короткий TTL помогает уменьшить время распространения изменений, но не гарантирует его.

VK Cloud не публикует оценок сроков миграции. На практике объём работ зависит прежде всего от stateful-слоя.

Если базы данных работают в управляемых СУБД вне кластера, переезд может уложиться в один рабочий цикл. Если базы и очереди находятся внутри Kubernetes, сроки нужно оценивать по каждому хранилищу отдельно.

Начинать лучше с dev-окружений. Там можно проверить переключение без риска для боевой нагрузки и найти зависимости от старой инфраструктуры.

Заключение

Выбор поколения — это выбор границы ответственности, а не версии сервиса.

Во втором поколении VK Cloud обслуживает системный слой в сервисном проекте, включает мониторинг и неизменяемую политику аудита, предоставляет Cilium, мультизональные классы хранения и отдельный набор аддонов. Взамен становятся недоступны Terraform, Kubernetes Dashboard и аддоны первого поколения, а GPU и vGPU в тарификации отнесены к первому поколению.

Перед переходом стоит проверить кластер в двух плоскостях: сначала инструменты и способ управления, затем данные. Первый список обычно небольшой, а второй определяет сроки, риски и порядок всей миграции.