有关 Azure Kubernetes 服务 (AKS) 中的基本计划程序功能的最佳做法

在 Azure Kubernetes 服务 (AKS) 中管理群集时，通常需要隔离团队和工作负荷。 Kubernetes 计划程序允许你控制计算资源的分布，并限制维护事件的影响。

本最佳做法文章重点介绍面向群集操作员的基本 Kubernetes 计划功能。在这篇文章中，你将学会如何：

使用资源配额为团队或工作负荷提供固定数量的资源
使用 Pod 中断预算减少计划内维护带来的影响

强制实施资源配额

最佳实践指南

在命名空间级别规划和应用资源配额。使用配额和限制范围来要求或提供 Pod 的默认资源请求和限制。监视资源用量并根据需要调整配额。

在 Pod 规范中设置资源请求和资源限制。资源请求是 Kubernetes 调度器用来决定将 Pod 调度到何处的 CPU 或内存资源量。资源限制限制容器可以使用的资源量。系统通过限流来强制执行 CPU 限制，同时在发生内存不足（OOM）时以被动方式终止进程，从而强制执行内存限制。有关详细信息，请参阅定义 Pod 资源请求和限制。

使用 资源配额 限制开发团队或项目的聚合资源消耗。在命名空间级别定义以下项的配额：

计算资源：例如 CPU 和内存，或 GPU。
存储资源：包括给定存储类的总卷数或磁盘空间量。
对象计数，例如可以创建的机密、服务或作业的最大数目。

Kubernetes 调度器使用资源请求为 Pod 分配节点。当容量可用时，容器可以使用比请求更多的 CPU 或内存，资源限制可能超过请求。资源配额单独限制聚合命名空间消耗。如果创建或更新资源将超过硬配额，API 服务器会拒绝使用 HTTP 403 Forbidden 响应的请求。即使配额导致其控制器无法创建所请求的全部 Pod，你仍然可以创建工作负载对象，例如 Deployment。

如果资源配额跟踪 CPU 或内存，则每个新 Pod 必须指定该资源的请求或限制。否则，API 服务器可能会拒绝 Pod。可以使用 LimitRange 为命名空间配置默认请求和限制。

以下名为 dev-app-team-quotas.yaml 的示例 YAML 清单设置了总共 10 个 CPU、20Gi 内存和 10 个 pod 的硬限制：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-app-team
spec:
  hard:
    cpu: "10"
    memory: 20Gi
    pods: "10"

此配额将命名空间中的 CPU 请求总量限制为 10 个 CPU、内存请求总量限制为 20Gi，并将非终止 Pod 的数量限制为 10 个。

将此资源配额应用于命名空间，例如 开发应用：

kubectl apply -f dev-app-team-quotas.yaml --namespace dev-apps

请咨询应用程序开发人员和所有者以了解其需求，并应用适当的资源配额。

有关可用资源对象、范围和优先级的详细信息，请参阅 Kubernetes 中的资源配额。

使用 Pod 中断预算 (PDB) 来限制中断的影响

最佳实践指南

为复制的应用程序定义 Pod 中断预算（PDB），以限制在 AKS 节点耗尽等事件期间并发自愿逐出。维护足够正常的副本，并在工作负荷允许时至少允许一个中断，以便群集维护可以继续。

导致 Pod 被移除的中断性事件分为两类：

非自愿性中断

非自愿性中断是群集操作员或应用程序所有者无法以一般方式进行控制的事件。示例包括：

物理计算机上的硬件故障
内核 Panic
删除节点 VM

可以通过以下方法缓解非自愿中断：

在部署中使用 Pod 的多个副本。
在 AKS 群集中运行多个节点。

自愿性中断

_ 自愿中断_ 是由集群操作员或应用程序所有者请求的事件。示例包括：

在群集升级期间清空节点
更新部署模板
直接删除 Pod

并非所有自愿中断都受到 PDB 的限制。直接删除 Pod 或工作负荷对象会绕过 PDB，而部署和 StatefulSet 等工作负荷控制器在滚动更新期间不受 PDB 的限制。单独配置工作负荷的推出策略，以在应用程序更新期间保持可用性。有关详细信息，请参阅 Kubernetes 中的中断。

PDB 通过 Kubernetes 驱逐 API 限制对选定 Pod 的并发自愿驱逐。在 AKS 滚动升级期间，AKS 会根据节点池设置增加浪涌容量，将某个节点设为不可调度并腾空该节点，然后重装映像或替换已腾空的节点。逐出 API 在清空期间评估 PDB。逐出后，工作负荷控制器将创建一个替换 Pod，计划程序将它置于具有可用容量的节点上。限制性 PDB、运行正常的副本不足或群集容量不足可能会延迟或阻止排出。

设置可用 Pod 的最小数量

假设有一个 ReplicaSet，其中包含五个带有 app: nginx-frontend 标签的 NGINX Pod。在自愿中断事件（如群集升级）期间，必须至少保留三个 Pod 可用。以下 PodDisruptionBudget 清单定义了此要求：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 3
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

该预算要求至少三个带有标签 app: nginx-frontend 的 Pod 在主动驱逐期间保持健康。

可以指定百分比，例如 60%，因此当 ReplicaSet 缩放时预算会调整。

设置最大不可用 Pod 数

PDB 可以定义任一 minAvailable 或 maxUnavailable两者，但不能同时定义这两者。若要基于不可用 Pod 的数量约束自愿驱逐，请将 maxUnavailable 指定为整数或百分比。以下清单仅在逐出后 ReplicaSet 中不可用的 Pod 数量不超过两个时，才允许自愿逐出：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  maxUnavailable: 2
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

仅当逐出后带有 app: nginx-frontend 标签的 Pod 中不可用的数量不超过两个时，此预算才允许自愿逐出。非自愿中断仍可能导致可用性低于此阈值。

AlwaysAllow 不健康 Pod 驱逐策略允许节点排空驱逐正在运行但不健康的 Pod。如果没有此设置，默认的 IfHealthyBudget 策略可能会在等待不健康的 Pod 恢复健康期间阻止清空操作。当可排空性比让不健康的 Pod 有更多时间恢复更重要时，请使用 AlwaysAllow。

将要使用的 PDB 清单保存为 nginx-pdb.yaml，然后将其应用到 AKS 群集：

kubectl apply -f nginx-pdb.yaml

在群集维护之前，请验证每个 PDB 是否允许预期的逐出：

kubectl get poddisruptionbudgets --namespace <namespace>

值为 0 的 ALLOWED DISRUPTIONS 可能会阻止 AKS 节点排空。与应用程序开发人员和所有者合作，以维护足够的正常运行的副本，并选择平衡应用程序可用性与维护要求的预算。

有关使用 Pod 中断预算的详细信息，请参阅为应用程序指定中断预算。

本文重点介绍基本的 Kubernetes 计划程序功能。有关 AKS 中的群集操作的详细信息，请参阅以下最佳做法文章：

Last updated on 2026-08-28