Гибридный кластер — это статический кластер Deckhouse Kubernetes Platform (DKP), расширенный за счёт узлов, размещённых в инфраструктуре поддерживаемого провайдера, например Yandex Cloud, VMware Cloud Director или VMware vSphere.

В таком сценарии control plane и исходные узлы кластера остаются частью статического кластера DKP, а дополнительные узлы добавляются через модуль соответствующего провайдера. Эти узлы могут создаваться автоматически через API провайдера или подключаться вручную, если виртуальные машины были созданы заранее.

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

Гибридная интеграция выполняется на базе уже развёрнутого статического кластера DKP (clusterType: Static). Затем включается модуль соответствующего облачного провайдера, через который DKP получает информацию о внешней инфраструктуре и может создавать или подключать дополнительные узлы.

В зависимости от провайдера узлы можно добавлять автоматически через API провайдера или подключать заранее созданные виртуальные машины вручную через bootstrap-скрипт.

Общие принципы гибридной интеграции описаны на этой странице. Порядок подготовки инфраструктуры и добавления узлов зависит от используемого провайдера и приведён в отдельных инструкциях:

Типы групп узлов

В гибридном сценарии DKP используются следующие типы групп узлов:

  • CloudEphemeral — узлы, которые DKP создаёт и удаляет автоматически через API настроенного облачного провайдера.
  • CloudStatic — узлы, которые создаются пользователем вручную или внешними инструментами в той же облачной инфраструктуре, с которой настроена интеграция у облачного провайдера. На таких узлах работает CSI, а объект Node управляется cloud-controller-manager: он автоматически обогащается информацией о зоне и регионе по данным провайдера.

Способы добавления узлов

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

  • Автоматическое создание облачных узлов. DKP создаёт виртуальные машины через API провайдера. Параметры ВМ описываются ресурсом *InstanceClass, а требуемое количество узлов и зоны размещения — ресурсом NodeGroup с типом CloudEphemeral.
  • Подключение вручную созданных облачных узлов через bootstrap-скрипт. Виртуальная машина создаётся пользователем заранее в инфраструктуре провайдера, после чего на ней запускается bootstrap-скрипт DKP для подключения узла к кластеру. Для такого сценария используется NodeGroup с типом CloudStatic. Такой узел управляется cloud-controller-manager соответствующего провайдера.

В этом разделе описаны общие сетевые требования для гибридных кластеров. Требования, связанные с конкретными провайдерами, включая сетевые параметры, шаблоны виртуальных машин, учётные данные, параметры размещения и способы добавления узлов, приведены в отдельных инструкциях для Yandex Cloud, VCD и vSphere.

Общие сетевые требования

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

Связность должна обеспечивать:

  • доступ подключаемых узлов к Kubernetes API исходного кластера;
  • доступ подключаемых узлов к DNS-серверам;
  • доступ подключаемых узлов к хранилищу образов контейнеров и другим внешним сервисам, необходимым для загрузки образов и пакетов;
  • доступ control plane и системных компонентов к подключаемым узлам для работы kubelet, сетевых компонентов, мониторинга и служебных операций Kubernetes;
  • доступ компонентов DKP, взаимодействующих с инфраструктурой провайдера, к API соответствующего провайдера.

Полный перечень соединений приведён в разделе «Сетевое взаимодействие», а рекомендации по ограничениям доступа — в разделе «Настройка сетевых политик».

Дополнительно рекомендуется проверить:

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

Конкретные требования к сетям, подсетям, шаблонам виртуальных машин, учётным данным и дополнительным параметрам зависят от используемого провайдера инфраструктуры и приведены в разделе «Предварительные требования» для соответствующего провайдера.

Дополнительные ресурсы