Рекомендации по расширенным возможностям планировщика в службе Azure Kubernetes (AKS)

Статья
03/15/2023

При управлении кластерами в Cлужбе Azure Kubernetes (AKS) часто возникает необходимость изолировать команды и рабочие нагрузки. Дополнительные функции, предоставляемые планировщиком Kubernetes, позволяют управлять:

Какие модули pod можно назначать на определенных узлах.
Как приложения с несколькими модулями pod могут быть распределены в кластере.

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

Использование отметок и толерантностей для ограничения модулей pod, которые могут назначаться на узлах.
Назначение модулям pod предпочтений для запуска на определенных узлах с помощью селекторов узлов или подобия узлов.
Разделение или группирование модулей pod на основе их подобия или антиподобия.
Ограничьте планирование рабочих нагрузок, для которых требуются GPU только на узлах с графическими процессорами.

Выделение узлов на основе отметок и толерантностей

Общие рекомендации:

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

При создании кластера AKS можно развернуть узлы с поддержкой GPU или множеством мощных процессоров. Дополнительные сведения см. в статье Использование GPU в AKS. Такие узлы используются для рабочих нагрузок по обработке больших массивов данных, например для задач машинного обучения или искусственного интеллекта.

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

Такая поддержка различных узлов предоставляется с помощью пулов, состоящих из нескольких узлов. Кластер AKS поддерживает один или несколько пулов узлов.

Для ограничения рабочих нагрузок, которые могут выполняться на узлах, в планировщике Kubernetes используются параметры отметки и толерантности.

Отметка применяется к узлу для указания, что на этом узле можно назначить только определенные модули pod.
Затем примените толерантность к модулю pod, что позволит допускать толерантность узла.

При развертывании модуля pod в кластере AKS модули назначаются планировщиком Kubernetes только на те узлы, отметка которых соответствует имеющейся толерантности. Ограничения и разрешения работают вместе, чтобы гарантировать, что модули pod не запланированы на недопустимых узлах. К узлу применяется один или несколько запятнав, помечая узел таким образом, чтобы он не принимал никаких модулей pod, которые не допускают запятнания.

Например, представим, что в вашем кластере AKS используется пул узлов с поддержкой графического процессора (GPU). Задаем имя, например gpu, и значение для назначения. Если задать для этого параметра значение NoSchedule, планировщик Kubernetes не будет назначать модули pod с неопределенными толерантностями на узле.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name taintnp \
    --node-taints sku=gpu:NoSchedule \
    --no-wait

При применении ограничения к узлам в пуле узлов вы определяете допуск в спецификации pod, которая позволяет планировать на узлах. В следующем примере определяются значения sku: gpu и effect: NoSchedule, допускающие отметку, применяемую к пулу узлов, в предыдущем шаге:

kind: Pod
apiVersion: v1
metadata:
  name: tf-mnist
spec:
  containers:
  - name: tf-mnist
    image: mcr.microsoft.com/azuredocs/samples-tf-mnist-demo:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  tolerations:
  - key: "sku"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

При развертывании этого модуля pod, например с помощью kubectl apply -f gpu-toleration.yaml, планировщик Kubernetes может успешно назначить этот модуль pod на узлы с примененной отметкой. Такое логическое ограничение позволяет управлять доступом к ресурсам в пределах кластера.

Если вы применяете отметки, обсудите с владельцами и разработчиками приложений, какие толерантности нужны им для развертывания.

Дополнительные сведения об использовании нескольких пулов узлов в AKS см. в статье Создание нескольких пулов узлов для кластера в AKS.

Поведение отметок и толерантностей в AKS

При обновлении пула узлов в AKS отметки и толерантности применяются к новым узлам по определенному шаблону:

Кластеры по умолчанию, использующие Azure Масштабируемые наборы виртуальных машин

Вы можете отметить пул узлов с помощью API AKS, чтобы новые масштабированные узлы получили указанные в API отметки узла.

Предположим следующее.

Начнем с кластера с двумя узлами: node1 и node2.
Вы обновляете пул узлов.
Создаются два других узла: node3 и node4.
Соответственно, передаются отметки.
Исходные узлы node1 и node2 удаляются.

Кластеры без поддержки Масштабируемые наборы виртуальных машин

Снова предположим, что:

У вас есть кластер с двумя узлами: node1 и node2.
Вы обновляете пул узлов.
Создается дополнительный узел: node3.
Отметки из node1 применяются к node3.
Удаляется узел node1.
Для замены на исходный node1 создается новый node1.
Отметки узла node2 применяются к новому узлу node1.
Затем удаляется узел node2.

По сути, node1 становится node3, а node2 — новым node1.

При масштабировании пула узлов в AKS ограничения и допустимости не переносятся по умолчанию.

Управление назначением моделей pod с помощью селекторов узлов и подобия

Общие рекомендации

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

Отметки и толерантности логически изолируют ресурсы с помощью жесткого выключения. Если модуль pod не допускает отметку узла, она не назначается на узле.

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

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

Рассмотрим пример узлов с большим объемом памяти. Эти узлы могут отдавать предпочтение модулям pod, запрашивающим большой объем памяти. Но чтобы ресурсы не простаивали, узлы разрешают запускать и другие модули pod. В следующем примере команда добавляет пул узлов с меткой hardware=highmem в myAKSCluster в myResourceGroup. Все узлы в этом пуле узлов имеют эту метку.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name labelnp \
    --node-count 1 \
    --labels hardware=highmem \
    --no-wait

Затем спецификация pod добавляет свойство nodeSelector, чтобы задать селектор узла, соответствующий метке на узле:

kind: Pod
apiVersion: v1
metadata:
  name: tf-mnist
spec:
  containers:
  - name: tf-mnist
    image: mcr.microsoft.com/azuredocs/samples-tf-mnist-demo:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  nodeSelector:
      hardware: highmem

Если вы используете эти параметры планировщика, обсудите с владельцами и разработчиками приложений, как правильно задать спецификации pod.

Дополнительные сведения об использовании селекторов узла см. в статье Assigning Pods to Nodes (Назначение модулей pod на узлы).

Подобие узла

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

Вы можете требовать, чтобы планировщик Kubernetes сопоставлял модуль pod в соответствии с отмеченным узлом. Или
Вы можете отдать предпочтение сопоставлению, но разрешите назначать модуль pod другому узлу, если нет соответствующего.

В следующем примере для подобия узла задано значение requiredDuringSchedulingIgnoredDuringExecution. Этот параметр требует, чтобы планировщик Kubernetes использовал узел с соответствующей меткой. Если нет ни одного подходящего узла, модуль pod ожидает назначения. Чтобы разрешить назначение модуля pod другому узлу, можно вместо этого задать предпочтительное значениеDuringSchedulingIgnoreDuringExecution:

kind: Pod
apiVersion: v1
metadata:
  name: tf-mnist
spec:
  containers:
  - name: tf-mnist
    image: mcr.microsoft.com/azuredocs/samples-tf-mnist-demo:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: hardware
            operator: In
            values:
            - highmem

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

Дополнительные сведения см. в статье Affinity and anti-affinity (Подобие и анти-подобие).

Подобие между модулями pod и анти-подобие

Последний способ логической изоляции рабочих нагрузок планировщиком Kubernetes — использование параметров inter-pod affinity (подобие между модулями pod) и anti-affinity (анти-подобие). Эти параметры указывают, что либо не следует назначать модули pod на узел, для которого уже назначен соответствующий модуль pod, либо это следует сделать. По умолчанию планировщик Kubernetes пытается распределить множество модулей pod в наборе реплик по узлам. Вы можете задать это поведение более конкретными правилами.

Хороший пример — веб-приложение, использующее Кэш Azure для Redis.

Можно использовать правила антиподобия модулей pod для запроса, чтобы планировщик Kubernetes распределял реплики по узлам.
Затем можно использовать правила подобия, чтобы обеспечить назначение каждого компонента веб-приложения тому же узлу, что и соответствующий кэш.

Вот как выглядит распределение модулей pod между узлами:

Узел 1	Узел 2	Узел 3
веб-приложение-1	веб-приложение-2	веб-приложение-3
кэш-1	кэш-2	кэш-3

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

Полный пример этого веб-приложения с Кэшем Azure для Redis см. в статье Размещение модулей pod в одном и том же узле.

Дальнейшие действия

Эта статья посвящена расширенным возможностям планировщика Kubernetes. Дополнительную информацию об операциях кластера в AKS см. в рекомендациях на такие темы: