Если 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/v1alpha1kind: ModuleConfigmetadata: name: cloud-provider-dvpspec: version: 2 enabled: true settings: nodes: parameters: layout: Standard sshPublicKey: zones: - default provider: parameters: namespace: demo---apiVersion: v1kind: Secretmetadata: name: d8-credentials namespace: d8-cloud-provider-dvptype: cloud-provider.deckhouse.io/credentialsstringData: authScheme: kubeconfig secret: Настройки меняются командой 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 поддерживает создание гибридных кластеров с 2020 года. Новое в версии платформы 1.77 — единый способ описать облачный и гибридный кластеры, и виртуализация в Deckhouse Platform — наш первый провайдер на этой ступениКак мигрировать существующий кластер, если он развёрнут в виртуализации Deckhouse Platform
Кластеры, установленные со схемой DVPClusterConfiguration, нужно перевести на новую модель. Миграция обязательна, потому что поддержка старого формата конфигурации будет прекращена, а пока она не выполнена, обновление платформы может блокироваться.
Сам переход устроен так:
-
После обновления Deckhouse Platform на версию 1.77 модуль находит старую конфигурацию, собирает из неё ModuleConfig, секрет с учётными данными, DVPInstanceClass и NodeGroup для каждой группы узлов и складывает готовые манифесты в секрет
d8-migration-resources. -
В кластере загорается алерт
D8CloudProviderDVPMigrationPending. -
Администратор просматривает манифесты и применяет их одной командой:
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/v1alpha1kind: DVPInstanceClassmetadata: name: dvp-workerspec: 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/v1kind: NodeGroupmetadata: name: dvp-workerspec: 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
Источник: habr.com