Управление Static-узлами

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

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

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

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

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

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

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

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

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

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

1. Kube-apiserver:

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

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

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

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

1. Kube-apiserver:

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

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

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

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

   • вручную — с помощью подготовленных платформой bashible-скриптов;
   • вручную с последующей передачей узла под автоматическое управление CAPS;
   • автоматически, с помощью CAPS.
2. Capi-controller-manager — компонент, обеспечивающий жизненный цикл самого кластера и его узлов. Не заказывает узлы в облаке самостоятельно, работает с кастомными ресурсами более высокого уровня, не привязанного к инфраструктуре. Генерирует инфраструктурные кастомные ресурсы, оставляя всю работу для инфраструктурного провайдера, который развертывается модулем конкретного облачного провайдера. Для статических узлов это CAPS.
3. Caps-controller-manager — компонент, управляющий статическими узлами (ограниченно, без заказа узлов).
4. Использование Static-узлов возможно не только на bare metal, но и в облаке. В случае облака, такой узел не управляется cloud-controller-manager, даже если включен один из облачных провайдеров. Csi-driver также не устанавливается на такие узлы.
5. Автоматическое масштабирование узлов не поддерживается.