#Планирование узлов кластера

Кластер использует метки ролей узлов Kubernetes node-role.kubernetes.io/<role> для назначения различных ролей узлам. Для удобства описания мы называем этот тип меток метками ролей.

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

В кластере:

• Узлы управляющей плоскости помечены меткой роли node-role.kubernetes.io/control-plane.

  Примечание:

  До версии Kubernetes v1.24 сообщество также использовало метку node-role.kubernetes.io/master для обозначения узлов управляющей плоскости. Для обратной совместимости обе метки считаются действительными для идентификации узлов управляющей плоскости.

• Рабочие узлы по умолчанию не имеют меток ролей. Однако при необходимости вы можете явно назначить рабочему узлу метку роли node-role.kubernetes.io/worker.

Помимо этих стандартных меток ролей, вы также можете определить пользовательские метки ролей на рабочих узлах для их дальнейшей классификации по функциональным типам. Например:

• Вы можете добавить метку роли node-role.kubernetes.io/infra, чтобы обозначить узел как infra-узел, предназначенный для размещения инфраструктурных компонентов.

• Вы можете добавить метку роли node-role.kubernetes.io/log, чтобы обозначить узел как лог-узел, специализированный для размещения компонентов логирования.

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

#Создание Infra-узлов в немодифицируемом кластере

По умолчанию кластер содержит только узлы управляющей плоскости и рабочие узлы. Если вы хотите назначить некоторые рабочие узлы как infra-узлы, предназначенные для размещения инфраструктурных компонентов, необходимо вручную добавить соответствующую метку роли и taint этим узлам.

Примечание:

Операции, описанные в этом разделе, применимы только к немодифицируемым кластерам. То есть следующие операции не поддерживаются в облачных кластерах (например, управляемых кластерах EKS, развернутых через Alauda Container Platform EKS Provider Cluster Plugin), сторонних кластерах или кластерах, где узлы используют немодифицируемую ОС.

#Добавление Infra-узлов

#Шаг 1: Добавьте метку роли Infra к ресурсам узла

kubectl label nodes 192.168.143.133 node-role.kubernetes.io/infra="" --overwrite

Эта команда добавляет метку роли infra к узлу 192.168.143.133: node-role.kubernetes.io/infra: "", указывая, что узел является infra-узлом.

#Шаг 2: Добавьте taint к ресурсам узла

Добавьте taint, чтобы предотвратить планирование других рабочих нагрузок на infra-узел.

kubectl taint nodes 192.168.143.133 node-role.kubernetes.io/infra=reserved:NoSchedule

Эта команда добавляет taint node-role.kubernetes.io/infra=reserved:NoSchedule к узлу 192.168.143.133, указывая, что на этот узел могут быть запланированы только приложения, которые терпят этот taint.

#Шаг 3: Проверьте метку и taint

Проверьте, назначены ли узлу метка роли infra и taint:

# kubectl describe node 192.168.143.133
Name:               192.168.143.133
Roles:              infra
Labels:             node-role.kubernetes.io/infra=reserved
                    ...
Taints:             node-role.kubernetes.io/infra=reserved:NoSchedule

Вывод показывает, что узел 192.168.143.133 настроен как infra-узел и имеет taint node-role.kubernetes.io/infra=reserved:NoSchedule.

#Миграция Pod на Infra-узлы

Если вы хотите запланировать конкретный Pod на infra-узлы, необходимо выполнить следующие настройки:

• nodeSelector, ориентированный на метку роли infra.
• Соответствующие tolerations для taint infra-узла.

Ниже приведён пример манифеста Deployment, настроенного для запуска на infra-узле.

apiVersion: apps/v1
kind: Pod
metadata:
  name: infra-pod-demo
  namespace: default
spec:
  ...
  nodeSelector:
    node-role.kubernetes.io/infra: ""
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra
    value: reserved
    operator: Equal
  ...

nodeSelector гарантирует, что Pod будет запланирован только на узлах с меткой node-role.kubernetes.io/infra: "", а toleration позволяет Pod терпеть taint node-role.kubernetes.io/infra=reserved:NoSchedule.

С такими настройками Pod будет запланирован на infra-узле.

Примечание:

Перемещение Pod, установленных через OLM Operators или Cluster Plugins, на infra-узел не всегда возможно. Возможность перемещения таких Pod зависит от конфигурации каждого Operator или Cluster Plugin.

#Планирование пользовательских узлов

Помимо infra-узлов, вы можете назначить рабочие узлы для других специализированных целей — например, для размещения компонентов логирования, сервисов хранения или агентов мониторинга.

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

#Общие шаги для определения узлов с пользовательскими ролями

Процесс аналогичен созданию infra-узлов.

#Шаг 1: Добавьте пользовательскую метку роли

kubectl label nodes <node> node-role.kubernetes.io/<role>="" --overwrite

Замените <role> на желаемое имя роли, например monitoring, storage или log.

#Шаг 2: Добавьте соответствующий taint

kubectl taint nodes <node> node-role.kubernetes.io/<role>=<value>:NoSchedule

Замените <role> на имя вашей пользовательской роли, а <value> — на осмысленное описание, например reserved или dedicated. Это значение необязательно, но полезно для документации и ясности.

#Шаг 3: Проверьте конфигурацию

kubectl describe node <node>

Убедитесь, что поля Labels и Taints отражают вашу конфигурацию пользовательской роли.

#Пример: Создание узла, предназначенного для компонентов логирования

Если вы хотите создать узел специально для установки компонентов логирования, можно добавить роль log. В этом случае создайте log-узел следующим образом.

#Шаг 1: Добавьте метку роли Log

kubectl label nodes 192.168.143.133 node-role.kubernetes.io/log="" --overwrite

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

#Шаг 2: Добавьте taint к узлу

kubectl taint nodes 192.168.143.133 node-role.kubernetes.io/log=reserved:NoSchedule

Этот taint предотвращает развертывание незапланированных рабочих нагрузок на узле.

#Шаг 3: Проверьте метку и taint

Name:               192.168.143.133
Roles:              log
Labels:             node-role.kubernetes.io/log=reserved
                    ...
Taints:             node-role.kubernetes.io/log=reserved:NoSchedule

Это подтверждает, что узел успешно настроен как log-узел с соответствующей меткой и taint.

Следуя приведённым рекомендациям, вы сможете эффективно разделить узлы Kubernetes по их назначению, улучшить изоляцию рабочих нагрузок и обеспечить развертывание конкретных компонентов на соответствующим образом настроенных узлах.