Поделиться через

Настройка расширенных профилей планировщика в службе Azure Kubernetes (AKS) (предварительная версия)

В этой статье вы узнаете, как развернуть примерные профили планировщика в службе Azure Kubernetes Service (AKS) для настройки расширенного поведения планирования с использованием встроенных модулей планирования. В этом руководстве также объясняется, как проверить успешное применение пользовательских профилей планировщика, предназначенных для конкретных пулов узлов или всего кластера AKS.

Ограничения

  • AKS в настоящее время не управляет развертыванием сторонних планировщиков или модулей планирования вне основного дерева.
  • AKS не поддерживает встроенные модули планирования, предназначенные для планировщика aks-system. Это ограничение позволяет предотвратить непредвиденные изменения надстроек AKS, включенных в кластере. Кроме того, нельзя определить profile, называемую aks-system.

Предпосылки

Установка расширения Azure CLI aks-preview

Это важно

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

  1. aks-preview Установите расширение с помощью az extension add команды.

    az extension add --name aks-preview

  2. Обновите до последней aks-preview версии расширения с помощью az extension update команды.

    az extension update --name aks-preview

Регистрация флага функции предварительного просмотра конфигурации, определяемой пользователем, для планировщика

  1. Зарегистрируйте флаг функции UserDefinedSchedulerConfigurationPreview с помощью команды az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "UserDefinedSchedulerConfigurationPreview"

    Через несколько минут отобразится состояние Registered (Зарегистрировано).

  2. Когда состояние отражает зарегистрировано, обновите регистрацию поставщика ресурсов Microsoft.ContainerService с помощью az provider register команды.

    az provider register --namespace "Microsoft.ContainerService"

Активировать настройки профиля планировщика в кластере AKS

Вы можете включить настройку профиля расписания в новом или существующем кластере AKS.

  1. Создайте кластер AKS с включенной конфигурацией профиля планировщика, используя команду az aks create с флагом --enable-upstream-kubescheduler-user-configuration.

    # Set environment variables
export RESOURCE_GROUP=<resource-group-name>
export CLUSTER_NAME=<aks-cluster-name>

# Create an AKS cluster with schedule profile configuration enabled
az aks create \
--resource-group $RESOURCE_GROUP \ 
--name $CLUSTER_NAME \
--enable-upstream-kubescheduler-user-configuration \
--generate-ssh-keys

  2. После завершения процесса создания подключитесь к кластеру az aks get-credentials с помощью команды.

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

Проверка установки контроллера планировщика

  • После включения функции в кластере AKS убедитесь, что определение пользовательского ресурса (CRD) контроллера планировщика успешно установлено с помощью команды kubectl get.

    kubectl get crd schedulerconfigurations.aks.azure.com

    Замечание

    Эта команда не будет выполнена, если функция не была успешно включена в предыдущем разделе.

Настройте бин-пэкинг узла

Стратегия организации узлов bin-packing — это метод планирования, который повышает эффективность использования ресурсов за счёт увеличения плотности pod на узлах, соблюдая заданные параметры конфигурации. Эта стратегия помогает повысить эффективность кластера, свести к минимуму ненужные ресурсы и снизить эксплуатационные затраты на обслуживание неактивных или неиспользуемых узлов.

В этом примере настроенный планировщик приоритизирует размещение подов на узлах с высоким потреблением ЦП. Явно эта конфигурация позволяет избежать недостаточного использования узлов, которые по-прежнему имеют свободные ресурсы и помогают лучше использовать ресурсы, уже выделенные узлам. CRD должен называться upstream.

  1. Создайте файл с именем bin-pack-cpu-scheduler.yaml, с именем CRD - upstream, и вставьте следующий манифест:

    apiVersion: aks.azure.com/v1alpha1
kind: SchedulerConfiguration
metadata:
  name: upstream
spec:
  rawConfig: |
    apiVersion: kubescheduler.config.k8s.io/v1
    kind: KubeSchedulerConfiguration
    profiles:
    - schedulerName: node-binpacking-cpu-scheduler
      pluginConfig:
          - name: NodeResourcesFit
            args:
              scoringStrategy:
                type: MostAllocated
                resources:
                  - name: cpu
                    weight: 1
    • NodeResourcesFit гарантирует, что планировщик проверяет, имеет ли узел достаточно ресурсов для запуска модуля pod.
    • scoringStrategy: MostAllocated указывает планировщику предпочитать узлы с высоким уровнем использования ресурсов ЦП. Это помогает повысить эффективность использования ресурсов путем размещения новых подов на узлах, которые уже интенсивно используются.
    • Resources указывает, что CPU является основным оцениваемым ресурсом, и при весе 1 использование ЦП при планировании имеет относительно равный уровень важности.

  2. Примените манифест конфигурации планирования с помощью kubectl apply команды.

    kubectl apply -f bin-pack-cpu-scheduler.yaml

  3. Чтобы настроить этот механизм планирования для определенных рабочих нагрузок, обновите pod-развертывания с помощью следующего schedulerName:

    ...
...
    spec:
      schedulerName: node-binpacking-cpu-scheduler
...
...

Настройка распространения топологии подов

Распространение топологии модулей — это стратегия планирования, которая стремится равномерно распределять модули между зонами отказа (например, зонами доступности или регионами), чтобы обеспечить высокий уровень доступности и отказоустойчивость в случае сбоя зоны или узла. Эта стратегия помогает предотвратить риск размещения всех реплик pod в одном домене сбоя. Дополнительные рекомендации по настройке см. в документации по ограничениям распространения топологии Pod Kubernetes. CRD должен называться upstream.

  1. Создайте файл с именем pod-topology-spreader-scheduler.yaml, с именем CRD - upstream, и вставьте следующий манифест:

    apiVersion: aks.azure.com/v1alpha1
kind: SchedulerConfiguration
metadata:
  name: upstream
spec:
  rawConfig: |
    apiVersion: kubescheduler.config.k8s.io/v1
    kind: KubeSchedulerConfiguration
    profiles:
    - schedulerName: pod-distribution-scheduler
      pluginConfig:
          - name: PodTopologySpread
            args:
              apiVersion: kubescheduler.config.k8s.io/v1
              kind: PodTopologySpreadArgs
              defaultingType: List
              defaultConstraints:
                - maxSkew: 1
                  topologyKey: topology.kubernetes.io/zone
                  whenUnsatisfiable: ScheduleAnyway
    • PodTopologySpread подключаемый модуль инструктирует планировщику максимально равномерно распределять поды по зонам доступности.
    • whenUnsatisfiable: ScheduleAnyway указывает расписание для планирования модулей pod, несмотря на неспособность соответствовать ограничениям топологии. Это позволяет избежать сбоев планирования модулей pod, когда точное распределение невозможно.
    • List Тип применяет ограничения по умолчанию в виде списка правил. Планировщик использует правила в том порядке, в котором они определены, и они применяются ко всем подам, которые не указывают пользовательские ограничения распространения топологии.
    • maxSkew: 1 означает, что количество подов может отличаться не более чем на 1 между любыми двумя зонами доступности.
    • topologyKey: topology.kubernetes.io/zone указывает, что планировщик должен распределять поды по зонам доступности.

  2. Примените манифест конфигурации планирования с помощью kubectl apply команды.

    kubectl apply -f pod-topology-spreader-scheduler.yaml

  3. Чтобы настроить этот механизм планирования для определенных рабочих нагрузок, обновите pod-развертывания с помощью следующего schedulerName:

    ...
...
    spec:
      schedulerName: pod-distribution-scheduler
...
...

Назначение профиля планировщика для всего кластера AKS

  1. В конфигурации профиля планировщика обновите schedulerName поле следующим образом:

    ...
...
    - schedulerName: default_scheduler
...
...

  2. Переустановите манифест, используя команду kubectl apply.

    kubectl apply -f aks-scheduler-customization.yaml

    Теперь эта конфигурация станет операцией планирования по умолчанию для всего кластера AKS.

Настройка нескольких профилей планировщика

Вы можете настроить вышестоящий планировщик с несколькими профилями и настроить каждый профиль с несколькими подключаемыми модулями, используя один и тот же файл конфигурации. Как напоминание, CRD должен быть назван upstream, а пользователем настраиваемые поля включают percentageOfNodesToScore, podInitialBackoffSeconds, podMaxBackoffSeconds и profiles.

В следующем примере мы создадим два профиля планирования, называемые планировщиком-одним и планировщиком-двумя. Поля percentageOfNodesToScore, podInitialBackoffSecondspodMaxBackoffSecondsприменяются глобально ко всем профилям, определенным.

глобальные параметры

  • percentageOfNodesToScore указывает процент узлов кластера, которые планировщик оценивает во время оценки для балансировки точности планирования и скорости. Таким образом, процентУзловДляОценки: 40 означает, что планировщик будет выбирать 40% узлов вместо всего кластера.
  • podInitialBackoffSeconds определяет начальную задержку перед повторным повторением неудачной попытки планирования, чтобы предотвратить быстрые повторные попытки. Поэтому podInitialBackoffSeconds: 1 означает, что планировщик ожидает 1 секунду до первой повторной попытки.
  • podMaxBackoffSeconds Задает максимальную задержку, которую планировщик будет ждать между экспоненциальными попытками повторного отката для неподдающихся планированию pod. Таким образом podMaxBackoffSeconds: 8 означает, что задержка повторных попыток никогда не превысит 8 секунд, даже если время ожидания увеличивается.

scheduler-one определяет приоритет размещения подов между зонами и узлами для сбалансированного распределения со следующими настройками:

  • Применяет строгое зональное распределение и предпочтительное распределение узлов с помощью PodTopologySpread.
  • Учитывает жесткие правила аффинности pod и рассматривает мягкие правила аффинности с InterPodAffinity.
  • Предпочитает узлы в определенных зонах, чтобы уменьшить сетевое взаимодействие между зонами с помощью NodeAffinity.

scheduler-two приоритизирует размещение pod на узлах с доступными ресурсами хранилища, CPU и памяти для своевременного и эффективного использования ресурсов с помощью следующих параметров:

  • Гарантирует размещение pods на узлах, где PVC могут привязываться к PV с использованием VolumeBinding.
  • Проверяет, соответствуют ли узлы и томы зональным требованиям, используя VolumeZone для избежания доступа к хранилищу между зонами.
  • Определяет приоритеты узлов на основе использования ЦП, памяти и эфемерного хранилища NodeResourcesFit.
  • Предпочитает узлы, у которых уже есть необходимые образы контейнеров, используя ImageLocality.

Замечание

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

  1. Создайте файл с именем aks-scheduler-customization.yaml, с именем CRD - upstream, и вставьте следующий манифест:

    apiVersion: aks.azure.com/v1alpha1
kind: SchedulerConfiguration
metadata:
  name: upstream
spec:
  rawConfig: |
    apiVersion: kubescheduler.config.k8s.io/v1
    kind: KubeSchedulerConfiguration
    percentageOfNodesToScore: 40
    podInitialBackoffSeconds: 1
    podMaxBackoffSeconds: 8
    profiles:
      - schedulerName: scheduler-one
        plugins:
          multiPoint:
            enabled:
              - name: PodTopologySpread
              - name: InterPodAffinity
              - name: NodeAffinity
        pluginConfig:
          # PodTopologySpread with strict zonal distribution        
          - name: PodTopologySpread
            args:
              defaultingType: List
              defaultConstraints:
                - maxSkew: 2
                  topologyKey: topology.kubernetes.io/zone
                  whenUnsatisfiable: DoNotSchedule
                - maxSkew: 1
                  topologyKey: kubernetes.io/hostname
                  whenUnsatisfiable: ScheduleAnyway                  
          - name: InterPodAffinity
            args:
              hardPodAffinityWeight: 1
              ignorePreferredTermsOfExistingPods: false
          - name: NodeAffinity
            args:
              addedAffinity:
                preferredDuringSchedulingIgnoredDuringExecution:
                  - weight: 100
                    preference:
                      matchExpressions:
                        - key: topology.kubernetes.io/zone
                          operator: In
                          values: [westus3-1, westus3-2, westus3-3]
      - schedulerName: scheduler-two
        plugins:
          multiPoint:
            enabled:
              - name: VolumeBinding
              - name: VolumeZone
              - name: NodeAffinity
              - name: NodeResourcesFit
              - name: PodTopologySpread
              - name: ImageLocality
        pluginConfig:
          - name: PodTopologySpread
            args:
              defaultingType: List
              defaultConstraints:
                - maxSkew: 1
                  topologyKey: kubernetes.io/hostname
                  whenUnsatisfiable: DoNotSchedule 
          - name: VolumeBinding
            args:
              apiVersion: kubescheduler.config.k8s.io/v1
              kind: VolumeBindingArgs
              bindTimeoutSeconds: 300
          - name: NodeAffinity
            args:
              apiVersion: kubescheduler.config.k8s.io/v1
              kind: NodeAffinityArgs
              addedAffinity:
                preferredDuringSchedulingIgnoredDuringExecution:
                  - weight: 100
                    preference:
                      matchExpressions:
                        - key: topology.kubernetes.io/zone
                          operator: In
                          values: [westus3-1, westus3-2]
          - name: NodeResourcesFit
            args:
              apiVersion: kubescheduler.config.k8s.io/v1
              kind: NodeResourcesFitArgs
              scoringStrategy:
                type: MostAllocated
                resources:
                  - name: cpu
                    weight: 3
                  - name: memory
                    weight: 1
                  - name: ephemeral-storage
                    weight: 2

  2. Примените манифест с помощью kubectl apply команды.

    kubectl apply -f aks-scheduler-customization.yaml

Отключите конфигурацию профиля планировщика AKS

  1. Чтобы отключить конфигурацию профиля планировщика AKS и вернуться к конфигурации планировщика AKS по умолчанию в кластере, сначала удалите schedulerconfiguration ресурс с помощью kubectl delete команды.

    kubectl delete schedulerconfiguration upstream || true

    Замечание

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

  2. Отключите функцию с помощью az aks update команды с флагом --disable-upstream-kubescheduler-user-configuration .

    az aks update --subscription="${SUBSCRIPTION_ID}" \
--resource-group="${RESOURCE_GROUP}" \
--name="${CLUSTER_NAME}" \
--disable-upstream-kubescheduler-user-configuration

  3. Убедитесь, что функция отключена с помощью az aks show команды.

    az aks show --resource-group="${RESOURCE_GROUP}" \
--name="${CLUSTER_NAME}" \
--query='properties.schedulerProfile'

    Выходные данные должны указывать, что функция больше не включена в кластере AKS.

Часто задаваемые вопросы (FAQ)

Что произойдет, если я применяю неправильно настроенный профиль планировщика к кластеру AKS?

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

Как отслеживать и проверять, учитывает ли планировщик мою конфигурацию?

Существует три рекомендуемых метода для наблюдения за результатами примененного профиля планировщика:

  • Просмотрите журналы плоскости управления AKS kube-scheduler , чтобы убедиться, что планировщик получил конфигурацию из CRD.
  • Выполните команду kubectl get schedulerconfiguration. Выходные данные отображают состояние configuration: pending во время развертывания и Succeeded или Failed после того, как конфигурация будет принята или отклонена планировщиком.
  • Выполните команду kubectl describe schedulerconfiguration. В выходных данных отображается более подробное состояние планировщика, включая любую ошибку во время сверки и текущую конфигурацию планировщика.

Дальнейшие шаги

Дополнительные сведения о планировщике AKS и рекомендациях см. в следующих ресурсах:

  • Last updated on