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

На странице Управление узлами доступно управление жизненным циклом узлов и групп узлов в кластере. По умолчанию доступны 2 группы:

  1. Control Plane, в которую входят Master-узлы;
  2. Worker, в которую входят Worker-узлы.

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

Для определения типа масштабирования или изменения количества Worker-узлов нажмите на кнопку “Конфигурация группы” в блоке Worker-узлов.

Для просмотра или редактирования данных узла нажмите на название узла в группе.

На открывшейся странице доступно описание узла, состояние ClusterAPI, инфраструктуры и самого узла. Страница доступна для просмотра с момента запроса на добавление узла и позволяет отследить этапы создания узла.

Когда узел будет доступен, на странице отобразятся вычислительные ресурсы и будет доступна кнопка для перехода на дашборд Grafana.

Если в кластере настроен SR-IOV Network Operator и созданы виртуальные машины, то в блоке Сетевые интерфейсы будет доступна информация:

  • Имя интерфейса
  • Имя драйвера
  • Количество интерфейсов

На вкладке Поды представлен перечень подов выбранного узла.

На вкладке События отображаются стандартные события Kubernetes для ClusterAPI, инфраструктуры и самого узла. На вкладке отображается индикация количества событий.

На вкладке Лейблы и аннотации при необходимости можно присвоить лейблы и аннотации для ClusterAPI, инфраструктуры и самого узла.

Действия с узлами

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

  • Cordon (при нажатии название подменяется на Uncordon, отменяющую действие)
  • Drain (при нажатии кнопка Cordon подменяется на Uncordon)

Действие Drain по умолчанию игнорирует DaemonSet. Доступна опция: удалить данные EmptyDir.

При нажатии на кнопку Cordon узел блокируется для распределения новых подов. Работа существующих на узле подов не прерывается. Узел, заблокированный для распределения новых подов помечается в колонке “Scheduling” таблице узлов на странице “Управление узлами” признаком “Disabled”. После нажатия на кнопку Uncordon признак снимается с узла и не отображается в таблице.

При нажатии на кнопку “Drain” узел блокируется для распределения новых подов узла (получает признак “Cordoned”). Поды принудительно завершаются и перераспределяются на другие узлы. Все поды кроме жизненно важных принудительно завершаются и будут перераспределены на другие узлы кластера (если такие узлы есть). Узел, заблокированный для распределения подов помечается в колонке “Scheduling” таблице узлов на странице “Управление узлами” признаком “Disabled”. После нажатия на кнопку “Uncordon” признак снимается с узла и не отображается в таблице.

Удаление узла

Для удаления узла на странице узла нажмите на кнопку Удалить узел. В открывшемся окне необходимо выбрать, требуется удалить узел с последующим или удалить узел без пересоздания. Полное удаление узла доступно только при ручном масштабировании Worker-узлов. Выбор способа масштабирования находится на странице Управление узлами/Конфигурация группы. Обратите внимание! Перед удалением Worker-узла в кластере с провайдером Shturval Manual необходимо:

  1. выполнить Drain узла;
  2. убедиться, что поды узла успешно запустились на других узлах;
  3. удалить с узла Persistent Volumes;
  4. инициировать удаление узла.

Исключение из автоскейлинга

Вы можете защитить узел от удаления в случае автоскейлинга. Для этого на странице узла нажмите на кнопку Исключить из автомасштабирования. Опция доступна только для группы Worker-узлов с включенным автомасшабированием. Исключенные из автоскейлинга узлы будут отмечены на странице “Управление узлами” в колонке “Автомасштабирование” признаком “Запрещено”.

Поведение системы при отказе/недоступности узла

В случае отказа/недоступности узла кластер начинает перераспределять нагрузку с этого узла на другие только спустя 30-60 секунд. Это связано с настройками мониторинга здоровья узлов в kube-controller-manager, а так же настройкой kubelet.

Kubelet периодически уведомляет kube-apiserver о своём статусе с интервалом, заданным в параметре --node-status-update-frequency. Значение по умолчанию 10 секунд.

Controller manager проверяет статус Kubelet каждые –-node-monitor-period. Значение по умолчанию 5 секунд.

если Kubelet сообщит статус в пределах node-monitor-grace-period, то Controller manager считает что узел исправен

В случае отказа узла кластера происходит следующий алгоритм:

  • Kubelet отправляет свой статус kube-apiserver в соответствии с параметром nodeStatusUpdateFrequency = 10 сек.

  • Допустим, узел выходит из строя.

  • Controller manager будет пытаться проверить статус узла (от Kubelet) каждые 5 сек (согласно параметру --node-monitor-period).

  • Controller manager определит, что узел не отвечает, и даст ему тайм-аут –node-monitor-grace-period в 40 сек. Если за это время Controller manager не сочтет узел исправным, он установит статус NotReady.

В этом сценарии будут возможны ошибки при обращении к Pods, работающим на этом узле, потому что модули будут продолжать получать трафик до тех пор, пока узел не будет считаться неработающим (NotReady) через 45 сек.

Чтобы увеличить скорость реакции Kubernetes на отказ узлов кластера, вы можете изменить параметры:

  • --nodeStatusUpdateFrequency (по умолчанию 10 сек) в конфиге Kubelet /var/lib/kubelet/config.yaml

  • --node-monitor-period (по умолчанию 5 сек )

  • --node-monitor-grace-period (по умолчанию 40 сек)

Обратите внимание, что при уменьшении этих показателей вы увеличиваете риск ложного срабатывания недоступности узла, например, при высокой загрузке узла или временной сетевой недоступности узла. Это может привести к тому, что приложения и нагрузка в кластере будут перераспределяться на другие узлы без действительной необходимости.

Подробнее в официальной документации Kubernetes: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/

← Конфигурация узлов кластера
Менеджер сертификатов →