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

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

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

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

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

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

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. Cluster-autoscaler (Deployment) — дополнительный компонент Kubernetes, который автоматически изменяет количество узлов в кластере в зависимости от нагрузки. Подробнее с автоматическим масштабированием узлов можно ознакомиться в разделе документации по управлению узлами.

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

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

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 секунд, контроллер удаляет с него все поды и затем удаляет сам узел.

7. Standby-holder (Deployment) — под для резервирования узлов. При включенном параметре spec.cloudinstances.standby кастомного ресурса NodeGroup в соответствующей группе узлов во всех зонах создаются резервные узлы.

   Резервный узел — это узел кластера, на котором резервируются ресурсы, доступные в любой момент для масштабирования. Наличие такого узла позволяет cluster-autoscaler не ждать инициализации узла (которая может занимать несколько минут), а сразу размещать на нем нагрузку.

   Standby-holder не выполняет никакой полезной работы, а резервирует ресурсы, не позволяя cluster-autoscaler удалить временно неиспользуемый узел.

   У пода standby-holder минимальный PriorityClass, и он вытесняется с узла при появлении реальной нагрузки. Подробнее о приоритизации и вытеснении подов можно почитать в документации Kubernetes.

   Под содержит один контейнер reserve-resources.

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

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

1. Kube-apiserver:

   • получение секрета kube-system/d8-node-manager-cloud-provider для подключения к облаку;
   • работа с кастомными ресурсами 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.

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

1. Узлы эфемерны, автоматически создаются и удаляются модулем.
2. Для взаимодействия с инфраструктурой облака необходим установленный и настроенный облачный провайдер (cloud-provider-* на схеме). Включает также csi-driver и cloud-controller-manager.
3. Capi-controller-manager — компонент, обеспечивающий жизненный цикл самого кластера и его узлов. Не заказывает узлы в облаке самостоятельно, работает с кастомными ресурсами более высокого уровня, не привязанного к инфраструктуре. Генерирует инфраструктурные кастомные ресурсы, оставляя всю работу для инфраструктурного провайдера, который развертывается модулем конкретного облачного провайдера cloud-provider.
4. Cluster-autoscaler — обеспечивает автомасштабирование узлов кластера.
5. Поддерживается резервирование узлов.