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

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

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

В таблице для Control Plane и Workers вы можете включить отображение IP-адресов узлов. Чтобы воспользоваться этой опцией и настроить другие параметры, нажмите на шестеренку в правом верхнем углу таблицы отображения узлов и выберите необходимые параметры. По умолчанию отображение IP адреса отключено.

Группе узлов 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-узлов. Выбор способа масштабирования находится на странице Управление узлами/Конфигурация группы.

Для узлов группы ControlPlane полное удаление узлов заблокировано в интерфейсе. Реализована возможность удаления с пересозданием узла при условии, что в результате удаления узла в кластере должно остаться не менее двух работающих Master-узлов. Наличие двух работающих узлов проверяется на момент запроса на удаление. В случае несоблюдения условия, запрос на удаление будет недоступен.

При отправке запроса на удаление Master-узла необходимо ввести названием узла в качестве подтверждения намерения.

В случае, если узел по какой-либо причине выведен из строя и есть необходимость его оперативно удалить без ожидания завершения подов, отсоединения дисков и тп., добавьте такому узлу taint node.kubernetes.io/out-of-service=NoExecute. В таком случае при удалении k8s не будет ожидать стандартного завершения работы узла и в срочном порядке переподнимет поды на другом узле.

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

Вы можете защитить узел от удаления в случае автоскейлинга. Для этого на странице узла нажмите на кнопку Исключить из автомасштабирования. Опция доступна только для группы 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.