Управление узлами
На странице Управление узлами доступно управление жизненным циклом узлов и групп узлов в кластере. По умолчанию доступны 2 группы:
- Control Plane, в которую входят Master-узлы;
- 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-узлов с включенным автомасшабированием. Исключенные из автоскейлинга узлы будут отмечены на странице “Управление узлами” в колонке “Автомасштабирование” признаком “Запрещено”.
Поведение системы при отказе/недоступности узла
В случае отказа/недоступности узла кластер начинает перераспределять нагрузку с этого узла на другие только спустя 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 на отказ узлов кластера, отредактируйте кластерную конфигурацию и добавьте в нее свои значения для controller-manager.
Для этого запустите команду:
kubectl -n kube-system edit cm kubeadm-config
Для примера возьмем рекомендуемые значения от Kubernetes - https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kubernetes-reliability.md#fast-update-and-fast-reaction:
Значения extraArgs apiServer до изменения:
apiServer:
certSANs:
- 10.31.145.170
extraArgs:
authorization-mode: Node,RBAC
profiling: "false"
В результате изменений extraArgs apiServer должно получиться:
apiServer:
certSANs:
- 10.31.145.170
extraArgs:
authorization-mode: Node,RBAC
profiling: "false"
default-not-ready-toleration-seconds: "30"
default-unreachable-toleration-seconds: "30"
Значения extraArgs controllerManager до изменения:
controllerManager:
extraArgs:
profiling: "false"
В результате изменений extraArgs controllerManager должно получиться:
controllerManager:
extraArgs:
profiling: "false"
node-monitor-period: "2s"
node-monitor-grace-period: "20s"
Далее необходимо отредактировать kubelet конфигурацию. Для этого запустите команду:
kubectl -n kube-system edit cm kubelet-config
Значение до изменения: nodeStatusUpdateFrequency: 0s
Значение после изменения: nodeStatusUpdateFrequency: 4s
Выполните ниже приведенные команды последовательно на всех узлах кластера, чтобы перегенерировать static pod манифесты для kube-apiserver,kube-controller-manager,kube-scheduler и конфигурацию kubelet:
sudo kubeadm upgrade node phase control-plane --etcd-upgrade=false
sudo kubeadm upgrade node phase kubelet-config
sudo systemctl restart kubelet