На данной странице описана архитектура модуля 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) — разворачивается на определенной группе узлов при включённом параметре spec.fencing кастомного ресурса NodeGroup.

    После запуска агент активирует сторожевой таймер Watchdog и устанавливает специальный лейбл node-manager.deckhouse.io/fencing-enabled на узле, где он функционирует. Агент регулярно проверяет доступность API Kubernetes. Если API доступен, агент отправляет сигнал в Watchdog, сбрасывая сторожевой таймер. Также агент отслеживает специальные лейблы обслуживания на узле и, в зависимости от их наличия, включает или отключает Watchdog.

    В качестве Watchdog используется модуль ядра softdog с параметрами soft_margin=60 и soft_panic=1. Это означает, что время таймаута сторожевого таймера составляет 60 секунд. По истечении этого времени происходит kernel panic, и узел остается в этом состоянии до ручной перезагрузки.

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

    • fencing-agent — выполняет описанные выше проверки. Сигнал в Watchdog отправляется посредством записи в файл /dev/watchdog на хосте.

  4. Fencing-controller — контроллер, который отслеживает все узлы с установленным лейблом node-manager.deckhouse.io/fencing-enabled.

    Если какой-либо из узлов недоступен более 60 секунд, контроллер удаляет с него все поды и затем удаляет сам узел.

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

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

  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. Автоматическое масштабирование узлов не поддерживается.