Alauda Container Platform
  • Русский

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

    Кластер использует метки ролей узлов 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, чтобы обозначить узел как log-узел, специализированный для размещения компонентов логирования.

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

    Содержание

    Создание Infra-узлов в неиммутабельном кластере

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

    Примечание:

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

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

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

    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 к ресурсам Node

    Добавьте 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=""
                    ...
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 по их назначению, улучшить изоляцию рабочих нагрузок и гарантировать, что определённые компоненты будут развернуты на соответствующим образом настроенных узлах.