Модуль cloud-provider-openstack управляет взаимодействием с облачными ресурсами на базе OpenStack. Он позволяет модулю node-manager использовать ресурсы OpenStack при заказе узлов для описанной группы узлов.

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

Архитектура модуля

Для упрощения схемы приняты следующие допущения:

  • На схеме показано, что контейнеры разных подов взаимодействуют друг с другом напрямую. Фактически они взаимодействуют через соответствующие сервисы Kubernetes (внутренние балансировщики). Названия сервисов не указываются, если они очевидны из контекста. В остальных случаях название сервиса указано над стрелкой.
  • Поды могут быть запущены в нескольких репликах, однако на схеме все поды изображены в одной реплике.

Архитектура модуля cloud-provider-openstack на уровне 2 модели C4 и его взаимодействия с другими компонентами Deckhouse Kubernetes Platform (DKP) изображены на следующей диаграмме:

Архитектура модуля cloud-provider-openstack

Компоненты модуля

Модуль состоит из следующих компонентов:

  1. Сloud-controller-manager — Kubernetes external cloud provider for OpenStack, реализация Сloud сontroller manager для OpenStack. Обеспечивает взаимодействие с облаком на базе OpenStack и выполняет следующие функции:

    • реализует связь 1:1 между объектом узла в Kubernetes (Node) и виртуальной машиной в облачном провайдере. Для этого:

      • заполняет поля spec.providerID и nodeInfo ресурса Node;
      • проверяет наличие виртуальной машины в облаке и при ее отсутствии удаляет ресурс Node в кластере.
    • при создании ресурса Service типа LoadBalancer в Kubernetes создаёт балансировщик в облаке, который направляет трафик извне к узлам кластера;
    • создает сетевые маршруты для сети PodNetwork на стороне OpenStack.

    Подробнее о cloud-controller-manager можно почитать в документации Kubernetes.

    Состоит из одного контейнера:

    • openstack-cloud-controller-manager.

  2. Cloud-data-discoverer — отвечает за сбор данных из API облачного провайдера и предоставление их в виде секрета kube-system/d8-cloud-provider-discovery-data. Этот секрет содержит параметры конкретного облака, которые используется другими компонентами модуля cloud-provider-openstack.

    Состоит из следующих контейнеров:

    • cloud-data-discoverer — основной контейнер;
    • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к метрикам контейнера cloud-data-discoverer.

  3. CSI-драйвер (openstack) — реализация CSI-драйвера для OpenStack. С типовой архитектурой CSI-драйвера, используемого в модулях cloud-provider-* DKP, можно ознакомиться на соответствующей странице документации.

    CSI-драйвер (openstack) не поддерживает работу со снимками. По этой причине в поде csi-controller отсутствует сайдкар-контейнер snapshotter (external-snapshotter).

Взаимодействия модуля

Модуль взаимодействует со следующими компонентами:

  1. Kube-apiserver:

    • мониторинг ресурсов PersistentVolumeClaim, VolumeAttachment;
    • создание секрета kube-system/d8-cloud-provider-discovery-data;
    • синхронизация узлов Kubernetes с виртуальными машинами в облаке;
    • мониторинг сервисов типа LoadBalancer;
    • авторизация запросов на получение метрик.

  2. OpenStack:

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

С модулем взаимодействуют следующие внешние компоненты:

  1. Prometheus-main — сбор метрик cloud-data-discoverer.

Непрямые взаимодействия:

  1. Модуль cloud-provider-openstack предоставляет модулю node-manager следующие артефакты:

    • шаблоны для создания кастомных ресурсов для конкретного провайдера, которые cloud-provider-openstack использует для создания виртуальных машин в облаке;
    • секрет kube-system/d8-node-manager-cloud-provider, в котором содержатся все необходимые настройки для подключения к облаку и создания CloudEphemeral-узлов. Эти настройки прописываются в кастомных ресурсах, созданных на основе упомянутых выше шаблонов и учитывающих особенности провайдера.

  2. Модуль cloud-provider-openstack предоставляет компоненты Terraform/OpenTofu для OpenStack, которые используются при сборке исполняемого файла утилиты dhctl в модуле terraform-manager, такие как:

    • Terraform/OpenTofu-провайдер;
    • Terraform-модули;

    • layouts — набор схем размещения в облаке, определяющих, как создается базовая инфраструктура, как и с какими дополнительными характеристиками для данного размещения должны создаваться узлы. Например, в одной схеме узлы могут иметь публичные IP-адреса, а в другой — нет. Каждый layout включает три модуля:

      • base-infrastructure — базовая инфраструктура (например, создание сетей), может быть пустым;
      • master-node;
      • static-node.