在 Azure Kubernetes 服务（AKS）上配置高级调度器配置文件（预览版）

本文介绍如何在 Azure Kubernetes 服务（AKS）中部署示例计划程序配置文件，以使用树内计划插件配置高级计划行为。本指南还介绍如何验证针对特定节点池或整个 AKS 群集的自定义计划程序配置文件的成功应用。

局限性

AKS 当前不管理第三方计划程序或树外计划插件的部署。
AKS 不支持以 aks-system 调度器为目标的内置调度插件。此限制有助于防止群集上启用的 AKS 加载项发生意外更改。

先决条件

Azure CLI 版本 2.76.0 或更高版本。可通过运行 az --version 查找版本，运行 az upgrade 升级版本。如果需要安装或升级，请参阅安装 Azure CLI。
在 AKS 群集上运行的 Kubernetes 版本 1.33 或更高版本。
aks-preview Azure CLI 扩展版本18.0.0b27或更高版本。
在 Azure 订阅中注册功能标志。UserDefinedSchedulerConfigurationPreview
查看 AKS 上支持的高级调度概念和内置调度插件。

安装 `aks-preview` Azure CLI 扩展

重要

AKS 预览功能可在自助服务和自愿选择的基础上启用。预览版按“现状”和“视供应情况”提供，它们不包括在服务级别协议和有限保证范围内。 AKS 预览功能是由客户支持尽最大努力部分覆盖。因此，这些功能并不适合用于生产。有关详细信息，请参阅以下支持文章：

使用 aks-preview 命令安装 az extension add 扩展。
```
az extension add --name aks-preview
```
使用aks-preview命令更新到最新版本的az extension update扩展。
```
az extension update --name aks-preview
```

注册用户定义调度器配置预览功能标记

使用 UserDefinedSchedulerConfigurationPreview 命令注册 az feature register 功能标志。
```
az feature register --namespace "Microsoft.ContainerService" --name "UserDefinedSchedulerConfigurationPreview"
```
几分钟后，状态将显示为“已注册”。

使用 az feature show 命令验证注册状态。

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

当状态反映为已注册时，使用命令刷新 az provider register 资源提供程序的注册。
```
az provider register --namespace "Microsoft.ContainerService"
```

在 AKS 群集上启用计划程序配置文件配置

可以在新的或现有的 AKS 群集上启用计划配置文件配置。

在新群集上启用
在现有群集上启用

使用 az aks create 命令和 --enable-upstream-kubescheduler-user-configuration 标志创建启用调度程序配置文件的 AKS 群集。

# 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

创建过程完成后，使用 az aks get-credentials 命令连接到群集。

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

使用 [az aks update][az-aks-update] 命令在现有群集上启用计划程序配置文件设置。

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

# Enable schedule profile configuration on an existing AKS cluster
az aks update --subscription="${SUBSCRIPTION_ID}" \
--resource-group="${RESOURCE_GROUP}" \
--name="${CLUSTER_NAME}" \
--enable-upstream-kubescheduler-user-configuration

验证计划程序控制器的安装

在 AKS 群集上启用该功能后，使用 kubectl get 命令验证计划程序控制器的自定义资源定义（CRD）是否已成功安装。
```
kubectl get crd schedulerconfigurations.aks.azure.com
```
注释

如果在上一部分中未成功启用该功能，此命令将不会成功。

配置节点装箱算法

节点打包是一种调度策略，在设定的配置范围内，通过增加节点上 Pod 的密度来最大化资源利用率。此策略通过最大程度地减少浪费的资源并降低维护空闲或未充分利用的节点的运营成本，从而帮助提高群集效率。

在此示例中，配置的调度程序优先考虑将 Pod 调度到 CPU 使用率较高的节点上。显式地，此配置可避免节点的资源未被充分利用，并帮助更有效地利用已分配给节点的资源。

创建一个名为aks-scheduler-customization.yaml的文件，并将以下清单粘贴进去：
```
apiVersion: aks.azure.com/v1alpha1
kind: SchedulerConfiguration
metadata:
  name: upstream
spec:
  profiles:
  - schedulerName: node-binpacking-scheduler
    pluginConfig:
    - name: NodeResourcesFit
      args:
        scoringStrategy:
          type: MostAllocated
          resources:
          - name: cpu
            weight: 1
```
- NodeResourcesFit 确保计划程序检查节点是否有足够的资源来运行 Pod。
- scoringStrategy: MostAllocated 告知计划程序首选 CPU 资源使用率较高的节点。这通过在已“高度使用”的节点上放置新 Pod 来帮助实现 更好的资源利用率 。
- Resources 指定 CPU 是评分时考虑的主要资源，权重为 1 ，使得在调度决策中，CPU 使用率的优先级被赋予了相对平等的重要性级别。
使用 kubectl apply 命令应用计划配置清单。
```
kubectl apply -f aks-scheduler-customization.yaml
```
要针对特定工作负载使用此调度机制，请使用以下内容 schedulerName更新 Pod 部署：
```
...
...
    spec:
      schedulerName: node-binpacking-scheduler
...
...
```

配置 Pod 拓扑分布

Pod 拓扑分布是一种调度策略，旨在将 Pod 均匀分布在不同的故障域（例如可用区或地理区域）之间，以确保在发生区域或节点故障时实现高可用性和容错。此策略有助于防止将 Pod 的所有副本置于同一故障域中的风险。有关更多配置指南，请参阅 [Kubernetes Pod 拓扑分布约束文档] （https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/）。

创建一个名为aks-scheduler-customization.yaml的文件，并将以下清单粘贴进去：
```
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 插件指示计划程序尽量均匀地跨可用性区域分配 Pod。
- whenUnsatisfiable: ScheduleAnyway 指定计划程序来安排 Pod，尽管无法满足拓扑约束。这可以避免 Pod 调度在确切分发不可行时发生失败。
- List 类型将默认约束作为规则列表应用。计划程序按照定义的顺序使用规则，并应用于未指定自定义拓扑分布约束的所有 Pod。
- maxSkew: 1 表示在任意两个区域之间，Pod 的数量最多可以相差 1 个。
- topologyKey: topology.kubernetes.io/zone 指示调度器应将 Pod 分散到可用性区域。
使用 kubectl apply 命令应用计划配置清单。
```
kubectl apply -f aks-scheduler-customization.yaml
```
要针对特定工作负载使用此调度机制，请使用以下内容 schedulerName更新 Pod 部署：
```
...
...
    spec:
      schedulerName: pod-distribution-scheduler
...
...
```

将计划程序配置文件分配给整个 AKS 群集

在计划程序配置文件中，将schedulerName字段按如下所示进行更新：
```
...
...
`- schedulerName: default_scheduler` 
...
...
```
使用 kubectl apply 命令重新应用清单。
```
kubectl apply -f aks-scheduler-customization.yaml
```
现在，此配置将成为整个 AKS 群集 的默认 计划操作。

配置多个调度程序配置文件

可以使用多个配置文件自定义上游计划程序，并在使用相同的配置文件时使用多个插件自定义每个配置文件。在以下示例中，我们将创建两个名为 scheduler-one 和 scheduler-two 的计划配置文件：

scheduler-one 优先将 Pod 放置在区域和节点之间，以便通过以下设置实现均衡分布：
- 使用强制实施严格的区域分发和PodTopologySpread节点分发。
- 遵循硬Pod亲和性规则，并考虑软关联性规则 InterPodAffinity。
- 首选特定区域中的节点，以减少使用 NodeAffinity 的跨区域网络。
scheduler-two 优先将 Pod 放置在具有可用存储、CPU 和内存资源的节点上，以便根据以下设置有效和及时地利用资源：
- 确保 Pod 被放置在能够将 PVC 绑定到 PV 的节点上 VolumeBinding。
- 验证节点和卷是否通过 VolumeZone 满足区域要求，以避免跨区域存储访问。
- 根据 CPU、内存和临时存储利用率对节点进行优先级排序，并且使用 NodeResourcesFit。
- 优先使用已具备ImageLocality所需容器映像的节点。

注释

可能需要根据工作负荷类型调整区域和其他参数。

创建一个名为aks-scheduler-customization.yaml的文件，并将以下清单粘贴进去：

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: [chinanorth3-1, chinanorth3-2, chinanorth3-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: [chinanorth3-1, chinanorth3-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

使用 kubectl apply 命令来应用清单。

kubectl apply -f aks-scheduler-customization.yaml

禁用 AKS 计划程序配置文件设置

若要禁用 AKS 计划程序配置文件配置并还原到群集上的 AKS 计划程序默认配置，请先使用schedulerconfiguration命令删除kubectl delete资源。
```
kubectl delete schedulerconfiguration upstream || true
```
注释

确保上一步已完成并确认 schedulerconfiguration 资源已删除，然后再继续禁用此功能。

使用带有标志的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

使用 az aks show 命令验证该功能是否已禁用。

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

输出应指示在 AKS 群集上不再启用该功能。

常见问题 (FAQ)

如果将配置错误的调度器配置文件应用到 AKS 群集，会发生什么情况？

在您应用调度器配置文件后，AKS 会检查其中是否包含有效的插件和参数配置。如果配置针对不允许的调度程序或不正确地设置了内置调度插件，AKS 会拒绝该配置，并恢复到上一个已知的“已接受”调度程序配置。此检查旨在限制由于计划程序配置错误而导致对新 AKS 群集和现有 AKS 群集的影响。

如何监视和验证计划程序是否遵循我的配置？

有三种建议的方法可用于查看您应用的调度程序配置文件的结果：

查看 AKS kube-scheduler 控制平面日志，确保计划程序从 CRD 接收配置。
运行 kubectl get schedulerconfiguration 命令。输出在configuration: pending推出期间显示状态，或在计划程序接受或拒绝配置后显示Succeeded或Failed的状态。
运行 kubectl describe schedulerconfiguration 命令。输出显示计划程序更详细的状态，包括对帐期间出现的任何错误，以及有效的当前计划程序配置。

后续步骤

若要详细了解 AKS 计划程序和最佳做法，请参阅以下资源：

Last updated on 2025-11-20