Как устроена работа с провайдерами в платформе

От Cluster API к настройке экземпляра провайдера: пулы IP, шаблоны ВМ, ссылки на сервисы.

Под провайдером в платформе “Штурвал” понимается операторы Cluster API, связывающий провайдер инфраструктуры с платформой. Для интеграции используются файлы конфигурации - экземпляры провайдера. Для каждого типа провайдера инфраструктуры может быть создано множество экземпляров настройки.

Здесь описана общая модель: как платформа связывает инфраструктуру (vCenter, oVirt, облако и т.д.), Cluster API и объекты в интерфейсе (экземпляр провайдера, пул IP, шаблон ВМ). Ниже — порядок подготовки провайдеров к первому кластеру (пул → экземпляр → шаблон ВМ), если применимо к вашей среде.

Кратко о Cluster API

Платформа «Штурвал» использует Cluster API (CAPI) для декларативного управления жизненным циклом клиентских кластеров и узлов: в кластере управления создаются и согласуются ресурсы Cluster, Machine, MachineDeployment и связанные объекты. Обзор ресурсов и иерархии — в разделе Cluster API. Таблица основных API‑групп и Kind для жизненного цикла узлов — на странице Создание узлов при развертывании клиентского кластера.

Ядро CAPI в платформе — сервис Провайдер Cluster API (shturval-capi). Для каждой поддерживаемой инфраструктурной среды подключается отдельный инфраструктурный провайдер Cluster API (отдельный сервис в кластере управления): он создаёт виртуальные машины на основании шаблона в инфраструктурной среде. Ниже в таблице перечислены эти сервисы и ссылки на их описание.

Наглядно связка «администратор → CAPI в кластере управления → инфраструктурный провайдер → API виртуализации → узлы рабочего кластера» показана на схеме (на примере oVirt):

Иллюстрация: Кратко о Cluster API

Цепочка: администратор — Cluster API — инфраструктурный провайдер — среда виртуализации — узлы рабочего кластера

Какие термины важны не путать

  • Cluster API (CAPI) — механизм управления кластерами и узлами в Kubernetes; объекты CAPI находятся в кластере управления (см. Cluster API).
  • Провайдер инфраструктуры — виртуализация, облако или физические хосты, которые вы подключаете платформу «Штурвал»: oVirt, VMware vSphere, OpenStack, Yandex Cloud и т.д.
  • Провайдер Cluster API (инфраструктурный провайдер CAPI) — компонент в кластере управления (например, shturval-capvs для vSphere), реализующий контракт CAPI для конкретной среды. В веб-интерфейсе кластера управления такие компоненты могут называться, например, «Провайдер vSphere», «Провайдер oVirt».
  • Экземпляр провайдера — объект в разделе Провайдеры → Конфигурация провайдеров: подключение к вашей конкретной среде (vCenter, Engine oVirt, проект OpenStack и т.п.), учётные данные, зона/проект, при необходимости пул IP и шаблоны ВМ. Это настройка на стороне платформы.
  • Пул IP-адресов — диапазон адресов, из которого при настроенном пуле при создании кластера могут выбираться VIP для KubeAPI и Ingress (вместо этого адреса можно задать вручную — см. Пул IP-адресов). Механизм пулов предусмотрен не для всех инфраструктур (см. таблицу) .
  • Шаблон ВМ — образ виртуальной машины для поставки узлов; для Shturval v2 шаблон ВМ не используется (узлы — подготовленные хосты).

От абстрактного к конкретному

  1. Кластер управления инициализирует сервисы, в том числе shturval-capi и инфраструктурные провайдеры. Вам не требуется самостоятельно настраивать сервисы операторов.
  2. Инфраструктурный провайдер CAPI взаимодействует с API вашей среды виртуализации или облака и по ресурсам CAPI создаёт ВМ.
  3. В интерфейсе платформы вы настраиваете экземпляр провайдера (подключение к среде), при необходимости пул IP и шаблоны ВМ, после чего создаёте клиентские кластера.

Более подробно о роли Cluster API и подходе платформы — в статье Как Штурвал управляет облаками.

Экземпляр провайдера

Для каждой поддерживаемой инфраструктурной среды вы создаёте экземпляр — конфигурацию подключения к конкретной среде (Engine oVirt, vCenter, проект OpenStack и т.п.). Где это делается в интерфейсе: платформа Провайдеры → Конфигурация провайдеров или с главной страницы: вкладка Платформа → блок Провайдеры инфраструктуры → Управлять в карточке провайдеров; для сред с пулами IP сначала создаётся пул в Провайдеры → Пулы IP-адресов см. порядок подготовки: пул → экземпляр → шаблон.

Скриншот: вкладка «Платформа» — переход в конфигурацию провайдеров

Вкладка Платформа: карточка Провайдеры инфраструктуры и ссылка Управлять

Для создания экземпляра требуется, чтобы сервис инфраструктурного провайдера был включен в кластере управления. В блоке Сервисы провайдеров на странице Конфигурация провайдеров можно включать и отключать сервисы провайдеров (менять режим связанных SSC). После включения сервису необходимо время на запуск, может потребоваться несколько минут; когда он успешно развернётся, тип экземпляра провайдера автоматически станет доступным в списке Добавить экземпляр провайдера.

Если сервис провайдера отключён, ранее созданные экземпляры остаются доступными только для просмотра.

Обратите внимание! Критическим является только сервис провайдера, с которым развёрнут кластер управления: его нельзя отключить. Остальные инфраструктурные провайдеры при установке платформы выключены. Если платформа установлена давно и неиспользуемые провайдеры остались включёнными (в том числе с признаком критичности), их можно отключить — см. Отключение неиспользуемых сервисов провайдеров.

Добавление экземпляра провайдера — выбор типа В одном экземпляре задаются, в общем виде:

  • Учётные данные и параметры API;
  • Контекст среды (datacenter, проект, зона и т.д., в зависимости от типа);
  • Пул IP-адресов — только для инфраструктур, где пулы поддерживаются (Shturval v2, oVirt, zVirt, oVirt, HostVM, РЕД Виртуализация, ROSA Virtualization, VMware vSphere);
  • Шаблоны ВМ для версий Kubernetes — для провайдеров инфраструктуры, у которых узел создаётся из шаблона (см. раздел Шаблоны ВМ).

Экземпляр провайдера: блок шаблонов виртуальных машин и версий Kubernetes

Пошаговый порядок: пул IP и таблица по средам, затем экземпляр провайдера и шаблоны ВМ.

Инфраструктура, сервис Cluster API и пул IP

Ниже: какая инфраструктурная среда, какой сервис Cluster API документирован в поставке, доступен ли пул IP в интерфейсе (при необходимости) и где читать про настройку экземпляра в разделе «Провайдеры».

Инфраструктурная среда Пул IP (VIP KubeAPI / Ingress) Cluster API оператор провайдера Неймспейс провайдера Настройка в интерфейсе
Shturval v2 (bare metal / SSH) Да Провайдер Shturval v2 (shturval-capsm) shturval-capsm Shturval v2
oVirt (zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization и др.) Да Провайдер oVirt (shturval-capov) capov-system oVirt и подобные провайдеры
VMware vSphere Да Провайдер vSphere (shturval-capvs) capv-system VMware vSphere
OpenStack (VK Cloud, Selectel) Нет Провайдер OpenStack (shturval-capos) capos-system OpenStack и подобные провайдеры
Basis Dynamix Нет Провайдер Basis Dynamix (shturval-capbd) capbd-system Basis Dynamix
VMware vCloud Director Нет Провайдер vCloud Director (shturval-capvcd) capvcd-system VMware vCloud Director
Yandex Cloud Нет Провайдер Yandex Cloud (shturval-capy) capy-system Yandex Cloud

Шаблоны ВМ

Для провайдеров инфраструктуры, у которых узел кластера создаётся из образа ВМ (все кроме Shturval v2), шаблоны виртуальных машин готовят по одной общей методике. На странице экземпляра провайдера шаблон сопоставляют с версией Kubernetes, для которой он предназначен.

Для Shturval v2 шаблон не используется: узлы — это хосты с подготовленной ОС, которые добавляются в экземпляр. Kubernetes на такие хосты устанавливает и обновляет штатный механизм платформы Штурвал.

Гибридные кластеры

Узлы в одном кластере могут быть подготовлены несколькими провайдерами: основной провайдер инфраструктуры (VMware vSphere, zVirt, oVirt, HostVM, РЕД Виртуализация, ROSA Virtualization, OpenStack, Selectel, VK Cloud, Basis Dynamix, VMware vCloud Director, Yandex Cloud (любой провайдер кроме Shturval v2 как основного)) и дополнительные Worker-группы на хостах Shturval v2 — например, физические узлы с GPU при Control Plane узлах и Worker узлах на VMware vSphere. При создании кластера в мастере задаётся один провайдер; хосты Shturval v2 подключаются после развёртывания. См. Гибридные кластеры.

Отключение неиспользуемых сервисов провайдеров

При установке платформы, начиная с версии 2.14.0 включается и помечается как критически важный (spec.iscritical: true) только сервис того провайдера, с которым развёрнут кластер управления. Остальные инфраструктурные провайдеры остаются выключенными.

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

Обратите внимание! Не отключайте сервис провайдера, с которым развёрнут кластер управления, и сервисы провайдеров, которые используются клиентскими кластерами или экземплярами провайдеров.

Имена SSC — в таблице Инфраструктура, сервис Cluster API и пул IP. У каждого провайдера два связанных SSC: основной чарт (shturval-capvs, shturval-capov и т.д.) и чарт CRD (*-crds).

Через интерфейс

  1. На вкладке Платформа в карточке Провайдеры инфраструктуры нажмите Управлять.
Скриншот: вкладка «Платформа» — переход в конфигурацию провайдеров

Вкладка Платформа: карточка Провайдеры инфраструктуры и ссылка Управлять

  1. В блоке Сервисы провайдеров выключите переключатель у неиспользуемого провайдера.
  2. Дождитесь, пока связанные SSC перейдут в режим Выкл (Absent).

Переключение режима сервиса провайдера

Если переключатель заблокирован, сервис помечен как критический — выполните шаги ниже. Режим Выкл недоступен и на странице Установленные сервисы.

Если отключение в интерфейсе недоступно

В графическом интерфейсе на страницах Провайдеры и Установленные сервисы для критического сервиса заблокирована возможность отключения. Изменить критичность сервиса и отключить его можно только через SSC.

    В кластере управления: Сервисы и репозитории → Установленные сервисы → на карточке сервиса провайдера Управлять → вкладка Манифест. В спецификации задайте:

    spec:
  iscritical: false
  mode: absent

    Нажмите Проверить, затем Сохранить.

    В кластере управления:

    kubectl patch shturvalserviceconfig <имя-ssc> --type merge -p '{"spec":{"iscritical":false,"mode":"absent"}}'

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

    Частые ошибки

    Ошибка: «Нет свободных адресов в пуле»
    Решение: Добавьте диапазон в пул или освободите адреса (удалите кластер, который их использовал).

    Ошибка: «Проверка подключения не прошла»
    Решение: Проверьте URL, логин, пароль. Убедитесь, что с узлов платформы есть доступ к платформе виртуализации/облаку. Сверьте требования выбранного контура: открытый, закрытый — порты и направления трафика.

    Ошибка: «Шаблон не найден»
    Решение: Убедитесь, что шаблон создан по инструкции и добавлен в экземпляр провайдера для нужной версии Kubernetes.

    Ошибка: нельзя отключить сервис провайдера в интерфейсе
    Решение: На ранних установках неиспользуемые провайдеры могли остаться критическими. Снимите iscritical и задайте mode: absent в SSC — Отключение неиспользуемых сервисов провайдеров.

    Что читать дальше

    ← Работа с зеркалом после инсталляции
    Подготовка шаблона провайдера →