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

Типы узлов и механика добавления

В Deckhouse узлы разделяются на следующие типы:

• Static — управляются вручную, node-manager их не масштабирует и не пересоздаёт;
• CloudStatic — создаются вручную или любыми внешними инструментами, размещается в том же облаке, с которым настроена интеграция у одного из облачных провайдеров:
  • Узлы типа CloudStatic обладают рядом особенностей, связанных с интеграцией с облачным провайдером. Такие узлы управляются компонентом cloud-controller-manager, в результате чего:
    • в объект Node автоматически добавляются метаданные о зоне и регионе размещения;
    • при удалении виртуальной машины из облака, соответствующий объект Node также будет удалён из кластера;
    • доступна работа CSI-драйвера для подключения облачных дисков.
• CloudPermanent — постоянные узлы, создаваемые и обновляемые node-manager;
• CloudEphemeral — временные узлы, создаваемые и масштабируемые в зависимости от нагрузки.

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

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

Автоматическое развертывание, настройка и обновление узлов Kubernetes

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

Развертывание узлов Kubernetes

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

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

Поддержка актуального состояния узлов

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

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

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

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

Работа с узлами в поддерживаемых облаках

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

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

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

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

Масштабирование узлов в облаке

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

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

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

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

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

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

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

Работа со статическими узлами

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

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

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

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

Группировка узлов и управление группами

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

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

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

Что такое ресурс Instance

Ресурс 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).

Влияние параметров NodeGroup на обновление и перезапуск узлов

Параметр NG	Disruption update	Перезаказ узлов	Рестарт kubelet
chaos	-	-	-
cloudInstances.classReference	-	+	-
cloudInstances.maxSurgePerZone	-	-	-
cri.containerd.maxConcurrentDownloads	-	-	+
cri.type	- (NotManaged) / + (other)	-	-
disruptions	-	-	-
kubelet.maxPods	-	-	+
kubelet.rootDir	-	-	+
kubernetesVersion	-	-	+
nodeTemplate	-	-	-
static	-	-	+
update.maxConcurrent	-	-	-

Подробно о всех параметрах можно прочитать в описании кастомного ресурса NodeGroup.

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

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