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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Kube-apiserver:

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

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

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

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

  1. Kube-apiserver:

    • пересылает в bashible-api-server запросы на ресурсы bashible.

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

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

  1. Узлы постоянны, создаются, управляются и удаляются пользователем. Пользователь управляет узлами не напрямую в инфраструктуре, а через утилиту dhctl, запущенную в инсталляторе DKP.
  2. Terraform-manager — модуль, используемый для автоматического управления ресурсами облачной инфраструктуры. Он проверяет состояние Terraform и применяет недеструктивные изменения к инфраструктурным ресурсам. С архитектурой модуля можно ознакомиться на соответствующей странице документации.
  3. Csi-driver — используется для заказа дисков в облачной инфраструктуре.
  4. Cloud-controller-manager — используется для заказа балансировщиков и прочих инфраструктурных ресурсов согласно своей спецификации.
  5. Infrastructure-provider — не требуется, вся работа с узлами осуществляется пользователем через утилиту dhctl и модуль terraform-manager.
  6. Автоматическое масштабирование узлов не поддерживается.

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