Kubernetes-кластер на нескольких инфраструктурах: наш начальный шаг к единой модели конфигурации

Если Kubernetes-кластер живёт на нескольких инфраструктурах сразу — например, control plane и часть узлов на своей платформе виртуализации в ЦОД, а часть узлов в облаке, — рано или поздно вы упрётесь в одну и ту же проблему: настройка облачного провайдера выглядит по-разному в зависимости от того, как кластер создавался. Развернули кластер сразу в облаке — установщик один раз записал параметры провайдера в отдельный источник, и поменять их можно только служебной командой. Подключили провайдера к уже работающему статическому кластеру — конфигурация задаётся совсем иначе. Один и тот же провайдер, два разных способа его описать.

Мы выпустили апдейт, которое устраняет это различие. Теперь провайдер для виртуализации в Deckhouse Platform (cloud-provider-dvp) переведён на единую конфигурацию — нев зависимости от того, развёртывали в нём кластер с нуля или подключили к уже существующему. Провайдер для нашей виртуализации стал первым на данном пути, в дальнейшем аналогичный перевод затронет и остальные интеграции.

Изменения приехали с версии Deckhouse Platform 1.77 и доступны как в коммерческих редакциях платформы, так и в бесплатной Deckhouse Platform Open. Привет, я Петр Антонов, руководитель продуктовых направлений «Сети и провайдеры для частной инфраструктуры» в команде Deckhouse. Расскажу, что изменилось в настройках конфигурации, как перейти на них и почему это важный шаг.

Как было

Конфигурация провайдера, развёрнутого сразу при установке кластера, жила в ресурсе DVPClusterConfiguration. Его один раз писала утилита dhctl в момент создания кластера. Там же лежали:

• kubeconfig родительского кластера Deckhouse Platform, на котором развёрнута сама система виртуализации и в котором создаются ВМ для узлов кластеров Kubernetes. Они используют виртуализацию как провайдера инфраструктуры;

• описание master-узлов с отдельной копией параметров виртуальной машины.

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

Если же виртуализацию в Deckhouse Platform подключали не при установке, а к уже существующему статическому кластеру, всё выглядело иначе: настройка задавалась через сам компонент cloud-provider-dvp. То есть для одного и того же провайдера существовало два разных набора ресурсов и два способа их редактировать — в зависимости от того, как родился кластер.

Как теперь

В 1.77 настройка провайдера для встроенной в платформу виртуализации одинаковая в обоих сценариях и складывается из четырёх ресурсов:

• ModuleConfig задаёт схему размещения, открытый SSH-ключ, зоны, неймспейс в родительском кластере Deckhouse Platform. Там же живут настройки трёх частей модуля: узлов, хранилища и cloud-controller-manager. Любую часть можно включать и выключать отдельно.

• Секрет с учётными данными d8-credentials (тип cloud-provider.deckhouse.io/credentials) содержит kubeconfig для доступа к api родительского кластера. Таких секретов может быть несколько, под разные компоненты.

• DVPInstanceClass задаёт параметры виртуальных машин: ядра, хранилище, класс ВМ, диски, образ.

• NodeGroup описывает группы узлов. Master-узлы описываются такой же группой типа CloudPermanent, что и рабочие.

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata: name: cloud-provider-dvp
spec: version: 2 enabled: true settings: nodes: parameters: layout: Standard sshPublicKey: <SSH_PUBLIC_KEY> zones: - default provider: parameters: namespace: demo
---
apiVersion: v1
kind: Secret
metadata: name: d8-credentials namespace: d8-cloud-provider-dvp
type: cloud-provider.deckhouse.io/credentials
stringData: authScheme: kubeconfig secret: <KUBECONFIG_BASE64>

Настройки меняются командой d8 k edit mc cloud-provider-dvp, а после правки параметров постоянных узлов, как и раньше, нужен dhctl converge. Равным образом у схемы размещения появилась релиз: настройки прежнего формата ModuleConfig система сама переводит на версию 2, администратору остаётся вписать реальный SSH-ключ вместо плейсхолдера.

Зачем менять то, что работало

Ответ короткий: чтобы у кластера под управлением Deckhouse Platform не было «родной» инфраструктуры.

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

Так, ресурс DVPClusterConfiguration был своего рода свидетельством о рождении кластера. Он появлялся только при установке, был жёстко привязан к конкретной инсталляции кластера виртуализации Deckhouse Platform и существовал в одном экземпляре. У статического кластера, собранного на голом железе, такого ресурса не было вовсе — в этом и корень несовместимости: один и тот же провайдер по-разному «прописывался» в зависимости от истории кластера.

Одновременно гибридные кластеры — где control plane свой, а узлы заказываются у облачного провайдера — для Deckhouse Platform давно уже не новость. Сопровождение узлов на собственном железе внутри облачного кластера для vSphere и OpenStack стала доступна в платформе ещё в 2020 году. В следующем, 2021 году для таких узлов появился тип CloudStatic, а в Deckhouse Platform 1.76 тот же алгоритм заработал для провайдера встроенной виртуализации.

Задача была в другом. Исторически интеграция с облачным провайдером настраивалась по-разному в зависимости от того, как создавался кластер. Если кластер развёртывали в облаке, его параметры задавал установщик в отдельном ресурсе. Если провайдера подключали к уже существующему статическому кластеру, параметры задавались в конфигурации соответствующего модуля cloud-provider. В результате один и тот же провайдер описывался двумя разными способами.

В версии платформы 1.77 эта разница исчезает — пока для нашего провайдера. Кластер, развёрнутый в Deckhouse Platform установщиком, и статический кластер, к которому виртуализацию подключили позже как провайдера, описываются одинаковым набором ресурсов. Разница между ними сводится к тому, где стоит control plane. 

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

В частности, control plane и часть узлов могут работать на платформе виртуализации в собственном ЦОДе, а дополнительная группа узлов — в Yandex Cloud. Или разные группы узлов могут работать на двух системах виртуализации под одним control plane.

Сам Kubernetes изначально не рассчитан на некоторое количество инфраструктурных провайдеров в одном кластере. cloud-controller-manager отвечает за конкретную инфраструктуру и может удалить узел, которого не находит в «своём» облаке, а Cluster api исходит из модели, где кластер связан с одной инфраструктурой. Поэтому недостаточно просто научиться разрабатывать ВМ в ещё одном облаке — провайдеры должны уметь сосуществовать в одном кластере.

Каждый вендор закрывает этот разрыв собственным кодом. Наш путь такой: сначала одинаковый контракт конфигурации для всех провайдеров, потом их сочетание в одном кластере. Control plane одновременно остаётся на одной площадке, мы распределяем между инфраструктурами узлы, а не etcd. 

В Deckhouse Platform 1.77 это направление уже отражается в поведении собственного провайдера для встроенной виртуализации. Его cloud-controller-manager теперь пропускает узлы, чей providerID принадлежит другому провайдеру, и не пытается их удалить. Это необходимо для обеспечения корректной работы жизненного цикла кластера, узлы которого размещены в разных инфраструктурных сегментах.

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

Как мигрировать существующий кластер, если он развёрнут в виртуализации Deckhouse Platform 

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

Сам переход устроен так:

1. После обновления Deckhouse Platform на версию 1.77 модуль находит старую конфигурацию, собирает из неё ModuleConfig, секрет с учётными данными, DVPInstanceClass и NodeGroup для каждой группы узлов и складывает готовые манифесты в секрет d8-migration-resources. 

2. В кластере загорается алерт D8CloudProviderDVPMigrationPending.

3. Администратор просматривает манифесты и применяет их одной командой:

d8 k -n d8-cloud-provider-dvp get secret d8-migration-resources -o jsonpath='{.data.resources\.yaml}' | base64 -d | d8 k apply -f -

Узлы одновременно не пересоздаются. Алерт погаснет сам, когда модуль убедится, что все ресурсы на месте. Мы намеренно не стали использовать манифесты автоматически: поскольку конфигурация кластера меняет владельца, администратор должен увидеть, что именно он подписывает.

Ограничения провайдера и гибридных кластеров

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

Как попробовать

Для нового кластера, который вы развёртываете на виртуализации Deckhouse Platform, пример конфигурации соберётся автоматически в быстром старте. 

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

apiVersion: deckhouse.io/v1alpha1
kind: DVPInstanceClass
metadata: name: dvp-worker
spec: virtualMachine: cpu: cores: 4 coreFraction: 100% memory: size: 8Gi virtualMachineClassName: generic rootDisk: size: 20Gi storageClass: replicated image: kind: ClusterVirtualImage name: ubuntu-24-04-lts
---
apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata: name: dvp-worker
spec: nodeType: CloudEphemeral cloudInstances: classReference: kind: DVPInstanceClass name: dvp-worker minPerZone: 1 maxPerZone: 3 zones: - default

Описание параметров смотрите в документации модуля cloud-provider-dvp.

P. S.

Читайте другие новости от команды Deckhouse:

• Новый прикладной балансировщик с поддержкой Gateway api в Deckhouse Kubernetes Platform

• Deckhouse Kubernetes Platform CE теперь можно устанавливать в закрытом контуре

• Добавили ИИ-ассистента в Kubernetes-платформу: управление кластером на человеческом языке и планы на встроенную LLM