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

На странице Управление узлами доступно управление группами узлов, конфигурацией групп узлов, а также управлением объектами healthcheck для групп узлов кластера.

Страница разделена на блоки:

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

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

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

Конфигурация Control Plane

На странице “Управление узлами” клиентского кластера справа от названия группы ControlPlane узлов нажмите на кнопку “Конфигурация группы”. На открывшейся странице доступны вкладки:

  • Конфигурация машин;
  • MachineHealthCheck.

На вкладке “Конфигурация машин” есть возможность указать параметры ClusterAPI, KubeadmControlPlane и InfraMachineTemplate.

Конфигурация ClusterAPI

Название группы формируется по принципу название кластера плюс постфикс “-control-plane”.

  • запрашиваемое количество количество узлов. Для группы Master-узлов доступно только указание нечетного количества узлов, т.к. etcd размещен на Master-узлах и для получения кворума в etcd требуется нечетное количество узлов. Для обеспечения отказоустойчивости в кластере рекомендуется выделение 3 или 5 Master-узлов.
  • стратегия восстановления: RollingUpdate, т.е. изменения в конфигурации будут применяться последовательно. Для стратегии требуется указать количество дополнительных узлов (MaxSurge). Указать можно в абсолютных (целое) или относительных (в %) значениях.
  • nodeDeletionTimeout: определяет, как долго capi-controller-manager будет пытаться удалить узел, после того как ресурс Machine будет помечен на удаление. При значении 0 попытки удаления будут повторяться бесконечно. Если значение не указано, будет использовано значение по умолчанию (10 секунд) для этого свойства ресурса Machine.
  • nodeDrainTimeout - это общее количество времени, которое контроллер потратит на слив/освобождение узла. Значение по умолчанию равно 0, что означает, время ожидания освобождения узла не ограниченно по времени и может ожидать сколько угодно. ПРИМЕЧАНИЕ: NodeDrainTimeout отличается от kubectl drain --timeout.
  • nodeVolumeDetachTimeout - это общее количество времени, которое контроллер потратит на ожидание отсоединения всех томов (volumes). Значение по умолчанию равно 0, это означает, что тома (volumes) будут ожидать отсоединения без какого-либо ограничения по времени и может ожидать сколько угодно. По умолчанию для ресурса Machine установлено значение 10 секунд.

Конфигурация KubeadmControlPlane

Выберите стратегию ремедиации, т.е. восстановления узла после идентификации его как нездорового. Позволяет детально настроить порядок восстановления для группы ControlPlane. Для управления доступны параметры:

  • Максимум попыток (maxRetry) - максимальное количество повторных попыток при попытке исправления неисправной машины. Повторная попытка происходит, когда машина, созданная в качестве замены неисправной машины, также выходит из строя. Если не задано (по умолчанию), попытки исправления будут повторяться бесконечно.
  • Время попытки (retryPeriod) - параметр ожидания времени, которое должно пройти перед началом новой попытки создания машины, после неудачной попытки создания машины. По умолчанию не задано, что значит, что новая попытка будет произведена немедленно.
  • Минимальный период работоспособности (minHealthyPeriod)- период времени, по прошествии которого считать, что машина здорова. Приводит к сбрасыванию счетчика количества восстановления машины. Если машина помечена как неработоспособная по истечении minHealthyPeriod(по умолчанию 1 ч) с момента предыдущего исправления, это больше не считается повторной попыткой, поскольку предполагается, что новая проблема не связана с предыдущей.

Конфигурация InfraMachineTemplate

В блоке конфигурации InfraMachineTemplate есть возможность изменить параметры шаблона инфраструктуры, применив новые значения вручную или скопировав значения из другого существующего шаблона. В зависимости от вида провайдера, происходит редактирование/создание ресурса:

  • OVirtMachineTemplate;
  • VSphereMachineTemplate;
  • OpenStackMachineTemplate;
  • BasisMachineTemplate;
  • ShturvalMachineTemplate.

Для OVirtMachineTemplate доступны для конфигурации параметры:

  • CPU:
    • cores
    • sockets
    • threads
  • Объем RAM, Мб (sizemb)
  • Объем диска, Гб (osdisksizegb)
  • nics:
    • vnicprofile
  • Шаблон ВМ (template): доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер.

Для VSphereMachineTemplate доступны для конфигурации параметры:

  • datacenter (выпадающий список всех датацентров, доступных для сервисной учетной записи экземпляра провайдера)
  • datastore (выпадающий список всех датасторов, доступных для сервисной учетной записи экземпляра провайдера)
  • Объем диска, Гб (diskGiB)
  • Объем RAM, Мб (memoryMiB)
  • Folder (путь до места создания ВМ)
  • Количество ядер (numCPUs)
  • Имя сети (networkName)
  • Ресурсный пул (resourcePool)
  • Шаблон ВМ (template): доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер.

Для OpenStackMachineTemplate доступны для конфигурации параметры:

  • cloudName
  • flavor (типы ВМ)
  • sshKeyName
  • volumeType
  • Объем диска, Гб
  • Шаблон ВМ (template): доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер.

Для ShturvalMachineTemplate доступны для конфигурации параметры с помощью выбора или директивного указания лейблов хостов.

Управление MachineHealthCheck для Control Plane

  • Name формируется по правилу: название клиентского кластера с добавлением “-controlplane-healthcheck”.
  • MachineHealthCheck не запустит исправления, если будет превышено количество неработоспособных узлов, которое определено в MaxUnhealthy. Для Master-узлов MaxUnhealthy принимает значение “100%”, поэтому исправление машины будет выполнено, даже если все Master-узлы кластера неработоспособны.
  • nodeStartupTimeout - время ожидания присоединения узла к кластеру. Слишком маленькое значение может привести к тому, что виртуальной машине не хватит времени для создания и присоединения, попытки присоединить узел уйдут в цикл.

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

  • MachineHealthCheck сработает, если при проверке выявлено, что:
    • статус узла невозможно определить, то есть узел находится в состоянии Ready-Unknown;
    • узел нездоровый, то есть в состоянии Ready-False.
  • Timeout говорит о том, что по истечению 5 минут статус Master-узла будет считаться действительным. Timeout в 5 минут необходим, чтобы не происходило ложного перезапуска, пока узел переходит в исправное состояние. Увеличение периода Timeout может привести к длительным простоям рабочей нагрузки на неработоспособном узле.

Конфигурация группы Worker-узлов

На странице есть возможность добавить новую или изменить параметры конфигурации ранее созданных групп Worker-узлов. Название группы формируется по правилу: название клиентского кластера с добавлением запрашиваемого названия группы.

Конфигурация ClusterAPI

  • Выбор способа масштабирования узлов в группе:
    • Ручное. При этом доступно директивное указание запрашиваемого количества узлов в группе.
    • Автоматизированное. При этом доступно указание минимального и максимального количества узлов для группы.
  • Тип восстановления:
    • OnDelete. При наличии изменений старые узлы удаляются и поднимаются новые.
    • RollingUpdate. При наличии изменений новые узлы создаются с последовательной заменой старых. Рекомендуемый вариант. При этом требуется указать максимальное количество недоступных и дополнительных узлов.
  • minReadySeconds - минимальное количество секунд, в течение которых узел для созданной машины должен быть готов, прежде чем считать реплику доступной. По умолчанию 0 (машина будет считаться доступной, как только узел будет готов).
  • progressDeadlineSeconds - максимальное время в секундах, необходимое для выполнения развертывания, прежде чем оно будет считаться неудавшимся. Контроллер развертывания продолжит обработку неудавшихся развертываний. В состоянии Cluster API будет отображено условие с причиной ProgressDeadlineExceeded. По умолчанию 600 с.
  • revisionHistoryLimit - количество MachineSets, которые нужно сохранить для возможности отката. По умолчанию 1.
  • nodeDeletionTimeout: определяет, как долго capi-controller-manager будет пытаться удалить узел, после того как ресурс Machine будет помечен на удаление. При значении 0 попытки удаления будут повторяться бесконечно. Если значение не указано, будет использовано значение по умолчанию (10 секунд) для этого свойства ресурса Machine.
  • nodeDrainTimeout - это общее количество времени, которое контроллер потратит на слив/освобождение узла. Значение по умолчанию равно 0, что означает, время ожидания освобождения узла не ограниченно по времени и может ожидать сколько угодно. ПРИМЕЧАНИЕ: NodeDrainTimeout отличается от kubectl drain --timeout.
  • nodeVolumeDetachTimeout - это общее количество времени, которое контроллер потратит на ожидание отсоединения всех томов (volumes). Значение по умолчанию равно 0, это означает, что тома (volumes) будут ожидать отсоединения без какого-либо ограничения по времени и может ожидать сколько угодно. По умолчанию для ресурса Machine установлено значение 10 секунд.
  • роли: укажите через запятую роли, которые будут назначены группе. Каждая назначенная роль будет прописана в после “/” лейбл узла node-role.kubernetes.io/.

Конфигурация InfraMachineTemplate

В блоке конфигурации InfraMachineTemplate есть возможность изменить параметры шаблона инфраструктуры, применив новые значения вручную или скопировав значения из другого существующего шаблона. В зависимости от вида провайдера, происходит редактирование/создание ресурса:

  • OVirtMachineTemplate;
  • VSphereMachineTemplate;
  • OpenStackMachineTemplate;
  • BasisMachineTemplate;
  • ShturvalMachineTemplate.

Для OVirtMachineTemplate доступны для конфигурации параметры:

  • CPU:
    • cores
    • sockets
    • threads
  • Объем RAM, Мб (sizemb)
  • Объем диска, Гб (osdisksizegb)
  • nics:
    • vnicprofile
  • Шаблон ВМ (template): доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер.

Для VSphereMachineTemplate доступны для конфигурации параметры:

  • datacenter (выпадающий список всех датацентров, доступных для сервисной учетной записи экземпляра провайдера)
  • datastore (выпадающий список всех датасторов, доступных для сервисной учетной записи экземпляра провайдера)
  • Объем диска, Гб (diskGiB)
  • Объем RAM, Мб (memoryMiB)
  • Folder (путь до места создания ВМ)
  • Количество ядер (numCPUs)
  • Имя сети (networkName)
  • Ресурсный пул (resourcePool)
  • Шаблон ВМ (template): доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер.

Для OpenStackMachineTemplate доступны для конфигурации параметры:

  • cloudName
  • flavor (типы ВМ)
  • sshKeyName
  • volumeType
  • Объем диска, Гб
  • Шаблон ВМ (template): доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер.

Для ShturvalMachineTemplate доступны для конфигурации параметры с помощью выбора или директивного указания лейблов хостов.

Управление MachineHealthCheck для группы Worker-узлов

  • Name формируется: название клиентского кластера с добавлением названия группы и постфикса “-healthcheck”.
  • MaxUnhealthy определяет максимальное количество неработоспособных узлов. Если количество неработоспособных Worker-узлов будет превышать 40%, исправление не сработает.
  • nodeStartupTimeout - время ожидания присоединения узла к кластеру. Слишком маленькое значение может привести к тому, что виртуальной машине не хватит времени для создания и присоединения, попытки присоединить узел уйдут в цикл.
  • Прежде чем считать узел нездоровым, должно пройти 10 минут, указанные в NodeStartupTimeout. Ожидается, что этого времени достаточно для присоединения узла к кластеру.

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

  • MachineHealthCheck сработает, если при проверке выявлено, что:
    • статус узла невозможно определить, то есть узел находится в состоянии Ready-Unknown;
    • узел нездоровый, то есть в состоянии Ready-False.
  • Timeout говорит о том, что по истечению 5 минут статус worker-узла будет считаться действительным. Timeout в 5 минут необходим, чтобы не происходило ложного перезапуска, пока узел переходит в исправное состояние. Увеличение периода Timeout может привести к длительным простоям рабочей нагрузки на неработоспособном узле.

Вынесение Ingress на отдельные узлы

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

  1. добавить новую группу Worker-узлов;
  2. в качестве роли в новой группе прописать ingress;
  3. задать два узла в создаваемой группе;
  4. дождаться, пока узлы получат состояние Ready;
  5. перейти в неймспейс Ingress;
  6. перейти в Deployments.
  7. удалить поды этого Deployment. Они будут пересозданы на новых узлах.

Просмотр узла

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

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

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

← Audit Policy
Cluster Issuer →