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

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

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

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

Если необходимы дополнительные возможности или платформы машинного обучения для планирования и очередей пакетных рабочих нагрузок, можно установить и настроить Kueue в AKS , чтобы обеспечить эффективное планирование на основе политик в кластерах AKS.

Если требуется детальная конфигурация планировщика для оптимизации того, как модули pod и задания определяют приоритеты определенных узлов, ресурсов хранилища, топологии и т. д., вы можете настроить планировщик в AKS.

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

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

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

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

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

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

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

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

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

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

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

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

kind: Pod
apiVersion: v1
metadata:
  name: app
spec:
  containers:
  - name: app
    image: <your-workload>:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  tolerations:
  - key: "sku"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

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

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

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

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

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

Кластеры, использующие по умолчанию Azure Virtual Machine Scale Sets

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

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

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

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

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

1. У вас есть кластер с двумя узлами: node1 и node2.
2. Вы обновляете пул узлов.
3. Создается дополнительный узел: node3.
4. Таинты из node1 применяются к node3.
5. Узел node1 был удалён.
6. Для замены на исходный node1 создается новый node1.
7. Отметки узла node2 применяются к новому узлу node1.
8. Затем удаляется узел node2.

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

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

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

Руководство по передовым методам

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

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

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

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

Рассмотрим пример узлов с большим объемом памяти. Эти узлы отдают предпочтение 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: app
spec:
  containers:
  - name: app
    image: <your-workload>:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  nodeSelector:
      hardware: highmem

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

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

Привязка узла

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

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

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

kind: Pod
apiVersion: v1
metadata:
  name: app
spec:
  containers:
  - name: app
    image: <your-workload>: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, а не для pod, которые уже назначены на узлах.

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

Взаимное притяжение и антипатия между pod.

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

Например, у вас есть веб-приложение, которое также использует ресурс Управляемого Redis в Azure.

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

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

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

Полный пример этого веб-приложения с управляемым Redis в Azure см. в разделе "Расположение модулей (pods) на одном узле".

Следующие шаги

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

• Мультитенантность и изоляция кластера
• Основные функции планировщика Kubernetes
• Проверка подлинности и авторизация