На данной странице описана архитектура модуля node-manager для CloudStatic-узлов.

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

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

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

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

Архитектура модуля node-manager для CloudStatic-узлов

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

Bashible — это ключевой компонент подсистемы Cluster & Infrastructure, обеспечивающий работу модуля node-manager. При этом он не является компонентом модуля, поскольку работает на уровне ОС в качестве системной службы. Bashible подробно описан в соответствующем разделе документации

Модуль, управляющий CloudStatic-узлами, состоит из следующих компонентов:

  1. Bashible-api-server — Kubernetes Extension API Server, развернутый на master-узлах. Генерирует bashible-скрипты из шаблонов, хранящихся в кастомных ресурсах. При обращении к kube-apiserver за ресурсами, содержащими бандлы bashible, kube-apiserver перенаправляет запрос в bashible-api-server и возвращает сформированный результат. Подробнее с описанием работы bashible и bashible-api-server можно ознакомиться в соответствующем разделе документации.

  2. Capi-controller-manager (Deployment) — основные контроллеры из проекта Kubernetes Cluster API. Cluster API является расширением Kubernetes, которое дает возможность управлять кластерами как кастомными ресурсами внутри другого Kubernetes-кластера. Под capi-controller-manager состоит из следующих контейнеров:

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

  3. Caps-controller-manager (Deployment) — CAPI Provider Static (CAPS), реализация провайдера декларативного управления статическими узлами (серверами bare metal или виртуальными машинами) для проекта Cluster API Kubernetes. Работает как дополнение к capi-controller-manager.

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

  4. Early-oom (DaemonSet) — на каждом узле разворачивается под, который считывает из каталога /proc метрики по загрузке ресурсов на хосте и в случае повышенной нагрузки завершает поды раньше, чем это сделает kubelet. Early-oom по умолчанию включен, но его можно отключить в настройках модуля в случае, если он создаёт проблемы для нормальной работы узлов.

    Включает в себя следующие контейнеры:

    • psi-monitor — основной контейнер, который отслеживает метрику PSI (Pressure Stall Information), отражающую время, в течение которого процессы ожидают освобождения определённых ресурсов, таких как CPU, память или I/O;
    • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к метрикам early-oom.

  5. Fencing-agent (DaemonSet) и fencing-controller — компоненты, реализующие механизм fencing. Принцип работы компонентов подробно разобран в описании параметра spec.fencing.mode ресурса NodeGroup. Подробнее о том, как механизм fencing обрабатывает разные типы узлов, можно почитать в разделе «FAQ» документации модуля node-manager.

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

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

  1. Kube-apiserver:

    • работа с кастомными ресурсами Cluster API;
    • работа с ресурсами Node;
    • авторизация запросов на метрики.

  2. Файлы на узлах:

    • /proc — читает метрики PSI для OOM Kill;
    • /dev/watchdog — отправляет сигнал в Watchdog для сброса сторожевого таймера.

  3. Инфраструктура:

    • управление статическими узлами (ограниченно, без заказа узлов).

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

  1. Kube-apiserver:

    • выполняет mutating- и validating-вебхуки capi-controller-manager;
    • пересылает в bashible-api-server запросы на ресурсы bashible.

  2. Prometheus-main — сбор метрик компонентов модуля node-manager.

Особенности архитектуры, специфичные для CloudStatic-узлов

  1. Пользователь создает и настраивает узлы следующими способами:

    • вручную — с помощью подготовленных платформой bashible-скриптов;
    • вручную с последующей передачей узла под автоматическое управление CAPS;
    • автоматически, с помощью CAPS.
  2. Capi-controller-manager — компонент, обеспечивающий жизненный цикл самого кластера и его узлов. Не заказывает узлы в облаке самостоятельно, работает с кастомными ресурсами более высокого уровня, не привязанного к инфраструктуре. Генерирует инфраструктурные кастомные ресурсы, оставляя всю работу для инфраструктурного провайдера (CAPS).
  3. Caps-controller-manager — компонент, управляющий статическими узлами (ограниченно, без заказа узлов).
  4. Csi-driver — используется для заказа дисков в облачной инфраструктуре.
  5. Cloud-controller-manager — используется для заказа балансировщиков и прочих инфраструктурных ресурсов согласно своей спецификации.
  6. Infrastructure-provider конкретного облака не требуется, его роль выполняет caps-controller-manager.
  7. Автоматическое масштабирование узлов не поддерживается.

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