Подсистема Cluster & Infrastructure

Данный раздел посвящён архитектуре подсистемы Cluster & Infrastructure платформы Deckhouse Kubernetes Platform (DKP).

Подсистема Cluster & Infrastructure отвечает за инфраструктурную часть управления Kubernetes-кластером. Управление узлами кластера реализовано с помощью модуля node-manager, а взаимодействие с IaaS-провайдерами — через соответствующие модули семейства cloud-provider-.

В разделе описаны механизмы управления всеми используемыми в DKP типами узлов, а также гибридными группами узлов и кластерами.

В подсистему Cluster & Infrastructure также входят следующие модули:

• chrony — обеспечивает синхронизацию времени на всех узлах кластера;
• registry-packages-proxy — предоставляет внутренний прокси-сервер для пакетов хранилища образов контейнеров;
• terraform-manager — предоставляет инструменты для работы с состоянием Terraform в Kubernetes-кластере.

В подразделе также описана служба Bashible, которая является ключевым компонентом подсистемы Cluster & Infrastructure. Bashible используется модулем node-manager для управления конфигурацией узлов.

В Deckhouse Kubernetes Platform (DKP) узлы разделяются на следующие типы:

• CloudEphemeral — узлы автоматически заказываются, создаются и удаляются в настроенном облачном провайдере.
• CloudPermanent — постоянные узлы, создаваемые и обновляемые модулем node-manager. Узлы отличаются тем, что их конфигурация берется не из кастомного ресурса NodeGroup, а из специального ресурса ClusterConfiguration (например, AWSClusterConfiguration для AWS). Другое важное отличие в том, что для применения конфигурации таких узлов необходимо выполнить dhctl converge (запустив инсталлятор DKP). Примером CloudPermanent-узла облачного кластера является master-узел кластера.
• CloudStatic — создаются вручную или любыми внешними инструментами, размещается в том же облаке, с которым настроена интеграция у одного из облачных провайдеров:

Узлы типа CloudStatic обладают рядом особенностей, связанных с интеграцией с облачным провайдером. Такие узлы управляются компонентом cloud-controller-manager, в результате чего:

- в объект Node автоматически добавляются метаданные о зоне и регионе размещения;

- при удалении виртуальной машины из облака, соответствующий объект Node также будет удалён из кластера;

- доступна работа CSI-драйвера для подключения облачных дисков.

• Static — статический узел, размещенный на сервере bare metal или виртуальной машине. В случае облачной инфраструктуры такой узел не управляется компонентом cloud-controller-manager, даже если включен один из облачных провайдеров. Подробнее про работу со статическими узлами можно прочитать в документации модуля node-manager.

Узлы добавляются в кластер путём создания объекта NodeGroup, который описывает тип, параметры и конфигурацию группы узлов. В случае CloudEphemeral-групп DKP интерпретирует этот объект и автоматически создаёт соответствующие узлы, регистрируя их в Kubernetes-кластере. Для других типов NodeGroup (например, CloudPermanent или Static) создание и регистрация узлов должны быть выполнены вручную или внешними инструментами.

Также поддерживается сценарий гибридных групп, где одна NodeGroup может включать как развернутые в облаке узлы типа Static, так и статические узлы (серверы bare-metal, виртуальные машины). Например, основную нагрузку могут нести серверы bare-metal, а облачные инстансы использоваться как масштабируемое дополнение при пиковых нагрузках.

Автоматическое развертывание (в static/hybrid — частично), настройка и дальнейшее обновление ПО работают на любых кластерах, независимо от его размещения в облаке или на bare metal.

DKP автоматически разворачивает узлы кластера, выполняя следующие идемпотентные операции:

• Настройку и оптимизацию операционной системы для работы с containerd и Kubernetes:

устанавливаются требуемые пакеты из репозиториев дистрибутива;

настраиваются параметры работы ядра, параметры журналирования, ротация журналов и другие параметры системы.

• Установку требуемых версий containerd и kubelet, включение узла в кластер Kubernetes.
• Настройку nginx и обновление списка upstream для балансировки запросов от узла к Kubernetes API.

Для поддержания узлов кластера в актуальном состоянии могут применяться два типа обновлений:

• Обычные — такие обновления всегда применяются автоматически и не приводят к остановке или перезагрузке узла.
• Требующие прерывания (disruption). Пример таких обновлений — обновление версии ядра или containerd, значительная смена версии kubelet и т. д. Для этого типа обновлений можно выбрать ручной или автоматический режим (секция параметров disruptions). В автоматическом режиме перед обновлением выполняется корректная приостановка работы узла (drain) и только после этого производится обновление.

В один момент времени производится обновление только одного узла из группы и только в том случае, когда все узлы группы доступны.

DKP имеет набор встроенных метрик мониторинга, которые позволяют контролировать прогресс обновления, получать уведомления о возникающих во время обновления проблемах или о необходимости получения разрешения на обновление (ручное подтверждение обновления).

У каждого поддерживаемого облачного провайдера существует возможность автоматического заказа узлов. Для этого необходимо указать требуемые параметры для каждого узла или группы узлов.

В зависимости от провайдера этими параметрами могут быть:

• тип узлов или количество ядер процессора и объем оперативной памяти;
• размер диска;
• настройки безопасности;
• подключаемые сети и др.

Создание, запуск и подключение виртуальных машин к кластеру выполняются автоматически.

Возможны два режима масштабирования узлов в группе:

• Автоматическое масштабирование.

При дефиците ресурсов, наличии подов в состоянии Pending, в группу будут добавлены узлы. При отсутствии нагрузки на один или несколько узлов, они будут удалены из кластера. При работе автомасштабирования учитывается приоритет группы (в первую очередь будет масштабироваться группа, у которой приоритет больше).

Чтобы включить автоматическое масштабирование узлов, необходимо указать разные ненулевые значения минимального (minPerZone) и максимального (maxPerZone) количества узлов в группе.

• Фиксированное количество узлов.

В этом случае DKP будет поддерживать указанное количество узлов (например, заказывая новые в случае выхода из строя старых узлов).

Чтобы указать фиксированное количество узлов в группе и отключить автоматическое масштабирование, необходимо указать одинаковые значения параметров minPerZone и maxPerZone.

При работе со статическими узлами функции модуля node-manager выполняются со следующими ограничениями:

• Отсутствует заказ узлов. Непосредственное выделение ресурсов (серверов bare-metal, виртуальных машин, связанных ресурсов) выполняется вручную. Дальнейшая настройка ресурсов (подключение узла к кластеру, настройка мониторинга и т.п.) выполняются полностью автоматически (аналогично узлам в облаке) или частично.
• Отсутствует автоматическое масштабирование узлов. Доступно поддержание в группе указанного количества узлов при использовании Cluster API Provider Static (параметр staticInstances.count). Т.е. DKP будет пытаться поддерживать указанное количество узлов в группе, очищая лишние узлы и настраивая новые при необходимости (выбирая их из ресурсов StaticInstance, находящихся в состоянии Pending).

Настройка/очистка узла, его подключение к кластеру и отключение могут выполняться следующими способами:

• Вручную, с помощью подготовленных скриптов.

Для настройки сервера (ВМ) и ввода узла в кластер нужно загрузить и выполнить специальный bootstrap-скрипт. Такой скрипт генерируется для каждой группы статических узлов (каждого ресурса NodeGroup). Он находится в секрете d8-cloud-instance-manager/manual-bootstrap-for-<ИМЯ-NODEGROUP>.

Для отключения узла кластера и очистки сервера (виртуальной машины) нужно выполнить скрипт /var/lib/bashible/cleanup_static_node.sh, который уже находится на каждом статическом узле.

• Автоматически, с помощью Cluster API Provider Static.

Cluster API Provider Static (CAPS) подключается к серверу (ВМ) используя ресурсы StaticInstance и SSHCredentials, выполняет настройку, и вводит узел в кластер.

При необходимости (например, если удален соответствующий серверу ресурс StaticInstance или уменьшено количество узлов группы), Cluster API Provider Static подключается к узлу кластера, очищает его и отключает от кластера.

• Вручную с последующей передачей узла под автоматическое управление Cluster API Provider Static.

Функциональность доступна начиная с версии DKP 1.63.

Для передачи существующего узла кластера под управление CAPS необходимо подготовить для этого узла ресурсы StaticInstance и SSHCredentials как при автоматическом управлении в пункте выше, однако ресурс StaticInstance должен дополнительно быть помечен аннотацией static.node.deckhouse.io/skip-bootstrap-phase: "".

Группировка и управление узлами как связанной группой означает, что все узлы группы будут иметь одинаковые метаданные, взятые из кастомного ресурса NodeGroup.

Для групп узлов доступен мониторинг:

• с группировкой параметров узлов на графиках группы;
• с группировкой алертов о недоступности узлов;
• с алертами о недоступности N узлов или N% узлов группы и т. п.

Ресурс Instance в Kubernetes представляет собой описание объекта эфемерной виртуальной машины, но без конкретной реализации. Это абстракция, которая используется для управления машинами, созданными с помощью таких инструментов, как MachineControllerManager или Cluster API Provider Static.

Объект не содержит спецификации. Статус содержит:

1. Ссылку на InstanceClass, если он существует для данной реализации.
2. Ссылку на объект Node Kubernetes.
3. Текущий статус машины.
4. Информацию о том, как проверить логи создания машины (появляется на этапе создания машины).

При создании или удалении машины создается или удаляется соответствующий объект Instance. Самостоятельно ресурс Instance создать нельзя, но можно удалить. В таком случае машина будет удалена из кластера (процесс удаления зависит от деталей реализации).

Некоторые операции по изменению конфигурации узлов могут потребовать перезагрузки.

Перезагрузка узла может потребоваться при изменении некоторых настроек sysctl, например, при изменении параметра kernel.yama.ptrace_scope (изменяется при использовании команды astra-ptrace-lock enable/disable в Astra Linux).

В случае изменения параметров InstanceClass или instancePrefix в конфигурации DKP не будет происходить RollingUpdate. DKP создаст новые MachineDeployment, а старые удалит. Количество заказываемых одновременно MachineDeployment определяется параметром cloudInstances.maxSurgePerZone.

При обновлении, которое требует прерывания работы узла (disruption update), выполняется процесс вытеснения подов с узла. Если какой-либо под не может быть вытеснен, попытка повторяется каждые 20 секунд до достижения глобального таймаута в 5 минут. После истечения этого времени, поды, которые не удалось вытеснить, удаляются принудительно.

Функции управления узлами реализуются с помощью специально подготовленных bash-скриптов, называемых bashible. Так же называется служба, которая работает на узлах кластера и используется для запуска данных скриптов. Набор скриптов называется бандлом (bundle).

Используются 4 бандла:

• скрипты установки bashible;
• скрипты бутстрапа первого узла;
• скрипты настройки узла для определенного облачного провайдера (например, AWS);
• основные (common) скрипты.

Скрипты представляют собой gotemplate-шаблоны, что позволяет гибко настраивать узел в зависимости от группы. Сами скрипты должны быть написаны так, чтобы они могли корректно выполняться при повторном запуске в случае ошибки и при повторном прогоне. Отдельный скрипт называется степом (шагом).

Основные этапы настройки узла:

• Настройка NodeUser для обеспечения доступа к узлу.
• Установка CA-сертификатов.
• Создание и добавление в PATH каталога /opt/deckhouse/bin, в котором хранятся бинарные файлы.
• Скачивание необходимых пакетов из registrypackages.
• Установка и настройка CRI containerd.
• Скачивание и настройка kubernetes-api-proxy. Компонент отвечает за доступ к API Kubernetes, представляет собой NGINX с набором upstream-серверов к master-узлам. Это обеспечивает HA-доступ к API на случай, если один master-узел недоступен, а также балансировку нагрузки к API.
• Установка, настройка и запуск kubelet.
• Запуск службы bashible, которая выполняет bashible.sh каждую минуту.
• Перезагрузка узла при необходимости.

Учитывая большое количество модификаций bashible-скриптов для разных поддерживаемых ОС, хранить все варианты в базе etcd невозможно из-за ограничения на размер ключа, а также избыточной нагрузки на etcd. По этой причине был разработан компонент bashible-api-server, который генерирует bashible-скрипты из шаблонов, хранящихся в кастомных ресурсах.

Bashible-api-server представляет собой Kubernetes Extension API Server, который развертывается на master-узлах.

При обращении к kube-apiserver за ресурсами, содержащими бандлы bashible, kube-apiserver перенаправляет запрос в bashible-api-server и возвращает сформированный результат. Взаимодействия bashible и bashible-api-server показаны на схемах архитектуры модуля node-manager (например, на схеме для CloudEphemeral-узлов).

Bashible-api-server возвращает следующие ресурсы:

• bootstrap-скрипт второй фазы, который загружается из первой фазы;
• bashibles — скрипт bashible.sh;
• nodegroupbundles — в нем рендерится бандл, включающий набор скриптов для бутстрапа и настройки узла.

Все эти ресурсы можно получить как через API, так и с помощью команды kubectl, указав имя группы узлов:

• kubectl get bootstrap.bashible.deckhouse.io master -o yaml;
• kubectl get bashibles.bashible.deckhouse.io master -o yaml;
• kubectl get nodegroupbundles.bashible.deckhouse.io master -o yaml.

Также bashible-api-server вычисляет контрольную сумму всех скриптов группы узлов. Это необходимо для реализации механизма обновления и корректного обновления статуса группы. Контрольные суммы записываются в секрет d8-cloud-instance-manager/configuration-checksums. Изменение контрольной суммы инициирует перезапуск bashible-скриптов на узлах при изменении конфигурации. Кроме того, контрольная сумма службы bashible сбрасывается каждые 4 часа для принудительного перезапуска bashible.

Управление узлами кластера осуществляется с помощью модуля node-manager.

Архитектура модуля 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 для сброса сторожевого таймера.

Модуль взаимодействует с модулем cloud-provider через kube-apiserver, используя секрет kube-system/d8-node-manager-cloud-provider, для получения всех необходимых настроек подключения к облаку и создания CloudEphemeral-узлов. Также cloud-provider предоставляет модулю node-manager шаблоны для создания кастомных ресурсов Cluster API, специфичных для определенных провайдеров.

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

1. Kube-apiserver:

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

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

1. Узлы эфемерны, автоматически создаются и удаляются модулем.

2. Для взаимодействия с инфраструктурой облака необходим установленный и настроенный облачный провайдер (cloud-provider-* на схеме). Включает также csi-driver и cloud-controller-manager.

3. Capi-controller-manager — компонент, обеспечивающий жизненный цикл самого кластера и его узлов. Не заказывает узлы в облаке самостоятельно, работает с кастомными ресурсами более высокого уровня, не привязанного к инфраструктуре. Генерирует инфраструктурные кастомные ресурсы, оставляя всю работу для инфраструктурного провайдера, который развертывается модулем конкретного облачного провайдера cloud-provider.

4. Cluster-autoscaler — обеспечивает автомасштабирование узлов кластера.

5. Поддерживается резервирование узлов.

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

Модуль, управляющий 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.

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

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

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

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

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.

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

Архитектура модуля 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.

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

• вручную — с помощью подготовленных платформой bashible-скриптов;
• вручную с последующей передачей узла под автоматическое управление CAPS;
• автоматически, с помощью CAPS.

2. Capi-controller-manager — компонент, обеспечивающий жизненный цикл самого кластера и его узлов. Не заказывает узлы в облаке самостоятельно, работает с кастомными ресурсами более высокого уровня, не привязанного к инфраструктуре. Генерирует инфраструктурные кастомные ресурсы, оставляя всю работу для инфраструктурного провайдера, который развертывается модулем конкретного облачного провайдера. Для статических узлов это CAPS.

3. Caps-controller-manager — компонент, управляющий статическими узлами (ограниченно, без заказа узлов).

4. Использование Static-узлов возможно не только на bare metal, но и в облаке. В случае облака, такой узел не управляется cloud-controller-manager, даже если включен один из облачных провайдеров. Csi-driver также не устанавливается на такие узлы.

5. Автоматическое масштабирование узлов не поддерживается.

Следует различать гибридные группы узлов и гибридные кластеры:

• Гибридные группы узлов могут включать как развернутые в облаке Static-узлы, так и серверы, развернутые в собственном ЦОД заказчика (bare metal или виртуальные машины).

Например, основную нагрузку могут нести серверы bare metal, а облачные инстансы использоваться как масштабируемое дополнение при пиковых нагрузках. Так как и в ЦОД заказчика и в облаке используются узлы одного типа (Static), архитектура модуля node-manager в этом случае будет соответствовать варианту для Static-узлов. Единственным обязательным требованием является наличие L3-связи между собственным ЦОД и облаком. Например, Yandex Cloud предоставляет механизм Cloud Interconnect.

• Гибридные кластеры — это кластеры DKP, в которых одновременно присутствуют:

NodeGroup со Static-узлами, развернутыми в собственном ЦОД заказчика (bare metal или виртуальные машины);

NodeGroup с CloudEphemeral-узлами, развернутыми в облаке.

В этом случае будут развернуты компоненты, необходимые для управления узлами обоих типов. Архитектура модуля node-manager будет соответствовать варианту для Static-узлов. Дополнительно будут развернуты компоненты, необходимые для работы CloudEphemeral-узлов:

• cloud-provider — обеспечивает взаимодействие с облачной инфраструктурой. Требуется установленный и настроенный провайдер для соответствующего облака. Включает также csi-driver и cloud-controller-manager;
• cluster-autoscaler — обеспечивает автомасштабирование узлов кластера.

Как и для гибридных групп узлов, для работы гибридных кластеров требуется наличие L3-связи между собственным ЦОД и облаком.

Модуль terraform-manager предоставляет инструменты для работы с состоянием Terraform в кластере DKP.

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

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

1. Terraform-auto-converger — периодически (по умолчанию раз в час) проверяет состояние Terraform и применяет недеструктивные изменения к ресурсам инфраструктуры.

Компонент работает только с базовой инфраструктурой кластера. Узлы кластера автоматически к требуемому состоянию не приводятся. Периодичность проверки задается параметром autoConvergerPeriod.

Состоит из следующих контейнеров:

• to-tofu-migrator — init-контейнер для миграции состояния Terraform в OpenTofu. В контейнере запускается утилита dhctl с командой converge-migration;
• converger — основной контейнер, в котором запускается утилита dhctl с командой converge-periodical;
• kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к метрикам контейнера converger. Является Open Source-проектом.

2. Terraform-state-exporter — проверяет состояние Terraform и экспортирует связанные с ним метрики.

Состоит из следующих контейнеров:

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

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

1. Kube-apiserver:

• чтение и запись секрета с состоянием Terraform;
• авторизация запросов на получение метрик.

2. Облачная инфраструктура (или система виртуализации) — управляет базовыми инфраструктурными ресурсами и приводит их к желаемому состоянию.

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

• prometheus-main — сбор метрик terraform-auto-converger и terraform-state-exporter.

Для управления постоянными томами хранения в Deckhouse Kubernetes Platform (DKP) используется CSI-драйвер (плагин).

Container Storage Interface (CSI) — это стандартный интерфейс, который унифицирует доступ к хранилищам и упрощает интеграцию различных систем хранения в кластеры.

CSI-драйвер входит в состав модулей cloud-provider-* DKP. Хотя для каждого поддерживаемого облачного провайдера или системы хранения используется собственная реализация спецификации CSI, архитектура CSI-драйвера у всех реализаций одинакова. Реализации могут для некоторых модулей отличаться по составу возможностей (capabilities) и компонентов.

Далее описана типовая архитектура CSI-драйвера, используемая в DKP. Она включает все возможные компоненты и реализует всю функциональность, применяемую в модулях DKP.

Типовая архитектура CSI-драйвера на уровне 2 модели C4 и его взаимодействия с другими компонентами DKP изображены на следующей диаграмме:

CSI-драйвер состоит из следующих компонентов:

1. Csi-controller (Deployment) — Controller Plugin, отвечающий за глобальные операции с томами: создание и удаление, подключение и отключение от узлов, а также управление снимками. Например, в AWS этот компонент вызывает EC2 API для создания томов EBS.

Состоит из следующих контейнеров:

• controller — основной контейнер, реализующий функциональность CSI-драйвера (capabilities) в виде gRPC-сервисов Identity Service и Controller Service согласно спецификации CSI;
• сайдкар-контейнеры контроллера — поддерживаемые сообществом Kubernetes внешние контроллеры (external controllers).

Они необходимы, поскольку persistent volume controller, запущенный в kube-controller-manager (компонент control plane кластера DKP), не имеет интерфейса взаимодействия с CSI-драйверами. Внешние контроллеры следят за ресурсами PersistentVolumeClaim и вызывают соответствующие функции CSI-драйвера в контейнере controller. Они также выполняют служебные функции, такие как получение информации о плагине и его capabilities или проверка состояния драйвера (liveness probe).

Внешние контроллеры взаимодействуют c контейнером controller по gRPC через Unix-сокеты.

В csi-controller входят следующие внешние контроллеры:

• provisioner (external-provisioner) — отслеживает ресурсы PersistentVolumeClaim и вызывает RPC CreateVolume или DeleteVolume. Также использует RPC ValidateVolumeCapabilities для проверки совместимости;
• attacher (external-attacher) — отслеживает ресурсы VolumeAttachment после того, как под запланирован на узел, а также подключает и отключает тома через RPC ControllerPublishVolume и ControllerUnpublishVolume;
• resizer (external-resizer) — отслеживает обновления ресурсов PersistentVolumeClaim, расширяет тома с помощью RPC ControllerExpandVolume, если пользователь запросил больше дискового пространства для PVC и драйвер поддерживает capability EXPAND_VOLUME;
• snapshotter (external-snapshotter) — работает совместно с модулем snapshot-controller, следит за ресурсами VolumeSnapshotContent, а также управляет снимками томов через RPC CreateSnapshot, DeleteSnapshot и ListSnapshots (если драйвер это поддерживает);
• livenessprobe — отслеживает состояние CSI-драйвера через RPC Probe из Identity Service и предоставляет HTTP-эндпоинт /healthz, за которым следит kubelet. При неуспешной livenessProbe kubelet перезапускает под csi-controller.

2. Csi-node (DaemonSet) — Node Plugin, работающий на всех узлах кластера и отвечающий за локальное монтирование и размонтирование томов.

Внимание. У плагина есть привилегированный доступ к файловой системе каждого узла. В Linux для этого требуется capability CAP_SYS_ADMIN. Это необходимо для выполнения операций монтирования и работы с блочными устройствами.

Состоит из следующих контейнеров:

• node — основной контейнер, реализующий функции CSI-драйвера в виде gRPC-сервисов Identity Service и Node Service согласно спецификации CSI;
• node-driver-registrar — сайдкар-контейнер, регистрирующий Node Plugin в kubelet. Вызывает в контейнере node RPC GetPluginInfo и NodeGetInfo, чтобы получить информацию о плагине и узле. Взаимодействуют c контейнером node по gRPC через Unix-сокет.

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

1. Kube-apiserver — мониторинг ресурсов PersistentVolumeClaim, VolumeAttachment и VolumeSnapshotContent.
2. Облачная инфраструктура (или система виртуализации) — создание и удаление томов, подключение и отключение томов от узлов, управление снимками.

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

Kubelet:

• проверяет livenessProbe CSI-драйвера;
• регистрирует Node Plugin;
• вызывает RPC NodeStageVolume, NodeUnstageVolume, NodePublishVolume, NodeUnpublishVolume и NodeExpandVolume в Node Plugin.

Kubelet взаимодействует с Node Plugin по gRPC через Unix-сокет.