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

Основные понятия конфигурации планировщика для размещения рабочей нагрузки в службе Azure Kubernetes (AKS)

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

Сведения о планировщике AKS

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

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

Конфигурация планировщика AKS и стратегии планирования

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

  • Пакетные задания могут предпочесть сортировку на нескольких узлах (для повышения производительности) по сравнению с распространением с учетом топологии (для надежности).
  • Рабочие нагрузки, чувствительные к затратам, могут извлечь выгоду из уплотнения узлов для консолидации заданий и уменьшения расходов на неактивные вычислительные ресурсы.

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

Настраиваемые профили планировщика

Профиль планировщика — это набор одного или нескольких встроенных плагинов планирования и конфигураций, которые определяют, как запланировать pod. Ранее AKS управлял конфигурацией планировщика и не был доступен пользователям. Начиная с версии 1.33Kubernetes, теперь можно настроить и задать профиль планировщика (предварительная версия) для планировщика Kubernetes в кластере.

Каждый профиль планировщика имеет следующие компоненты:

Поддерживаемые встроенные модули планирования

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

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

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

Ограничения планирования и плагины на основе заказов

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

  • DefaultPreemption: обрабатывает предварительную обработку, которая является процессом вытеснения модулей pod с низким приоритетом, чтобы освободить место для модулей pod с более высоким приоритетом. Если pod не может быть запланирован, так как на узле недостаточно ресурсов, этот плагин вытесняет другие pod, чтобы освободить место. Этот подключаемый модуль может получить следующие аргументы:

    • PodPriority: определяет приоритет запланированного модуля pod.
    • PreemptionPolicy: политика обработки вытеснения pod (например, "PreemptLowerPriority" или "DoNotPreempt").
    • PodPriorityClass: класс приоритета, связанный с модулем pod.
    • PodInfo: сведения о модулях pod, которые являются кандидатами для предварительного прерывания.
    • Node: сведения о узле, на котором учитывается вытеснение.

  • SchedulingGates. Представляет концепцию планирования шлюзов, которые являются условиями, которые должны быть удовлетворены перед планированием модуля pod. Например, он может обеспечить завершение определенных задач или операций перед тем, как планировщик попытается запланировать запуск pod.

  • PrioritySort: сортирует список pod по классу их приоритета. Сначала запланированы модули pod с более высоким приоритетом. Он помогает принимать решения о вытеснении и определяет, какие поды следует учитывать для планирования по приоритету.

Ограничения выбора узлов для планировочных плагинов

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

    • Affinity: определяет обязательные или предпочтительный правила сходства для модуля pod, которые указывают другие модули pod, которые должны или не должны быть запланированы рядом.
    • TopologyKey: ключ, представляющий домен сбоя, к которому применяется правило сходства (например, "kubernetes.io/hostname" для сопоставления на уровне узла или "topology.kubernetes.io/zone" для уровня зоны).
    • Weight: определяет, насколько строго планировщик должен учитывать определенное правило сходства.
    • Pod: модуль pod, который планируется.
    • OtherPods: список других pod'ов, которые следует учитывать в отношении правил сходства.

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

    • NodeAffinity: определяет необходимые или предпочтительный правила сходства узлов, например requiredDuringSchedulingIgnoredDuringExecution или preferredDuringSchedulingIgnoredDuringExecution.
    • NodeSelectorTerms: определяет набор меток узлов и значений, которые должны соответствовать.
    • Pod: модуль pod, который планируется.
    • Node: потенциальный узел для планирования.
    • LabelSelector: селектор для выбора узлов на основе меток.

  • NodeName. Принудительное планирование модулей pod на определенном узле. При указании точного имени узла планировщик размещает pod на этом узле, если возможно.

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

  • NodeUnschedulable: гарантирует, что модули pod не запланированы на узлах, помеченных как незапланированные. Если узел запятнан с помощью node.kubernetes.io/unschedulable, планировщик не размещает новые pods на этом узле.

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

  • NodeVolumeLimits: Проверяет, превысил ли узел установленный лимит объема. Каждый узел имеет максимальное количество томов, которые он может подключить, и этот подключаемый модуль обеспечивает, что pod не запланирован на узле, который уже достиг этого поддерживаемого ограничения.

  • VolumeBinding: гарантирует, что постоянные тома (PV) правильно привязаны к модулям pod. Он проверяет, может ли том, который требуется модулю pod, быть привязан к узлу, и обеспечивает доступность тома на выбранном узле. Этот подключаемый модуль может получить следующие аргументы:

    • VolumeClaims: утверждения постоянного тома (PVCS), сделанные запланированным модулем pod.
    • Node: кандидат узел, который рассматривается для планирования.
    • VolumeAvailable: проверяет, доступен ли постоянный объём на узле или в соответствующей зоне.
    • Pod: модуль pod, запрашивающий привязку тома.
    • StorageClass: класс хранилища, связанный с постоянным томом.
    • VolumeBindingMode: Определяет, является ли режим привязки тома Immediate или WaitForFirstConsumer (для отложенной привязки, пока не будет запланирован под).

  • VolumeRestrictions: гарантирует, что ограничения томов (например, ограничения на количество томов, которые могут быть подключены) учитываются при планировании модуля pod. Он предотвращает планирование модуля pod на узле, в котором будут нарушены ограничения тома.

  • VolumeZone: гарантирует, что тома запланированы в той же зоне доступности, что и модуль pod. Например, если pod запрашивает том, который должен находиться в определенной зоне, плагин гарантирует, что pod и том находятся в одной зоне.

Подключаемые модули планирования оптимизации ресурсов и топологии

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

    • ResourceRequests: запросы ресурсов (ЦП, память и т. д.) запланированного модуля pod.
    • Node: кандидат на роль узла для планирования.
    • NodeResources: доступные ресурсы (ЦП, память и т. д.) узла.
    • ClusterResourceUsage: Метрики использования ресурсов на уровне кластера, которые помогут решить лучший узел для балансировки ресурсов.

  • NodeResourcesFit: проверяет, имеет ли узел достаточно доступных ресурсов (процессора, памяти и т. д.), чтобы запустить модуль. Это гарантирует, что pod запланирован только на узле с достаточным количеством доступных ресурсов. Этот подключаемый модуль может получить следующие аргументы:

    • ResourceRequests: запросы ресурсов модуля pod.
    • Node: кандидат узел, который рассматривается для планирования.
    • NodeCapacity: доступная емкость ресурсов на узле.
    • Pod: модуль pod, запланированный, с запросами ресурсов.

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

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

    • TopologySpreadConstraints: определяет ограничения для распределения модулей pod по доменам сбоев, включая ключ (например, topology.kubernetes.io/zone) и количество модулей pod, которые необходимо поместить в каждый домен.
    • Pod: модуль pod, который планируется.
    • FailureDomain: ключ домена сбоя (например, зона или регион).
    • PodAffinity: сведения о сопоставлении модулей pod, которые также могут повлиять на распределение модулей pod.
    • Node: потенциальные узлы для размещения.
    • PodSpreadScore: используется для определения количества "распространение" модуля pod между доменами (более высокие оценки указывают на лучшее распространение).

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

Настройте и разверните профиль планировщика (предварительная версия) в кластере AKS.

  • Last updated on