Azure Kubernetes Services (AKS) 中基本排程器功能的最佳做法

您在管理 Azure Kubernetes Service (AKS) 中的叢集時，往往需要隔離小組和工作負載。 Kubernetes 排程器讓你能控制運算資源的分配，並限制維護事件的影響。

本最佳做法文章著重於叢集操作員的基本 Kubernetes 排程功能。 在本文中，您將學會如何：

  • 利用資源配額給予團隊或工作負載固定數量的資源
  • 透過使用艙體中斷預算來限制定期維護的影響

強制執行資源配額

最佳做法指導方針

在命名空間層級規劃及套用資源配額。 使用配額和限制範圍來要求或提供預設的資源請求與限制。 監視資源使用量，並視需要調整配額。

在 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、20 Gi 的記憶體和 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 個。

將此資源配額套用到命名空間，例如 dev-apps：

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

請與您的應用程式開發人員和擁有者合作，了解他們的需求並套用適當的資源配額。

如需可用資源物件、範圍和優先順序的詳細資訊，請參閱 Kubernetes 中的資源配額。

透過使用Pod中斷預算（PDB）來限制中斷影響

最佳做法指導方針

為複製應用定義 Pod Disruption Budgets（PDB），以限制在 AKS 節點清理等事件期間同時自願驅逐的情況。 維持足夠多的健康副本，並在工作負載允許時允許至少一次中斷，以便叢集維護得以繼續進行。

移除 pod 的干擾性事件可分為兩類：

非自發性中斷

「非自發性中斷」是超過叢集操作員或應用程式擁有者一般控制力的事件。 範例包括：

  • 實體機器發生硬體故障
  • 核心恐慌
  • 刪除節點 VM

您可以透過以下方式來減輕非自願的干擾：

  • 在部署中使用多個 Pod 複本。
  • 在 AKS 叢集中運行多個節點。

自發性中斷

_ 自願disruptions_是叢集操作員或應用程式擁有者所請求的事件。 範例包括：

  • 在叢集升級過程中耗盡節點
  • 更新部署範本
  • 直接刪除 pod

並非所有自願中斷都受限於PDB。 直接刪除 pod 或 workload 物件會繞過 PDB，而像 Deployments 和 StatefulSets 這類工作負載控制器在滾動更新時也不受 PDB 限制。 分別設定工作負載的部署策略，以維持應用程式更新期間的可用性。 欲了解更多資訊，請參閱 Kubernetes 中的中斷。

PDB 透過 Kubernetes 驅逐 API 限制選定 pod 的同時自願驅逐。 在 AKS 滾動升級期間，AKS 會根據節點池設定增加突波容量，封鎖並排空節點，然後重新映像化或替換已耗盡的節點。 Eviction API 會在排水過程中評估 PDB。 驅逐後，工作負載控制器會建立一個替代 pod，排程器則將其放置在有可用容量的節點上。 限制性 PDB、健康複製體不足或叢集容量不足，都可能延遲或阻塞排水。

設定最低可用艙數

考慮一個 ReplicaSet，裡面有五個標記為 app: nginx-frontend的 NGINX Pod。 在自願干擾事件中，例如叢集升級時，至少必須有三個艙體保持可用。 以下 PodDisruptionBudget 清單定義了此要求：

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

此預算要求至少有三個帶有標籤 app: nginx-frontend 的 pods 在自願驅逐期間保持健康。

你可以設定百分比，例如 60%，這樣當 ReplicaSet 擴展時預算會調整。

設定最多無法使用艙數

PDB 可以定義其中一種 minAvailable 或 maxUnavailable，但不能兩者兼有。 為了限制因無法使用Pods而自願驅逐，請以整數或百分比來指定 maxUnavailable 。 以下清單僅允許在淘汰後複製組中不超過兩個 Pod 無法使用時，允許自願驅逐：

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

此預算僅允許在驅逐後標籤上最多只能有兩個可使用膠囊 app: nginx-frontend 時自願淘汰。 非自願的中斷仍可能導致可用時間低於此門檻。

AlwaysAllow不健康的莢囊驅逐政策允許排水管驅逐不健康的莢囊。 沒有這個設定，預設 IfHealthyBudget 策略可能會在等待不健康 pod 恢復健康時阻擋排水。 在可排水性比給不健康小隊更多時間恢復更重要時使用 AlwaysAllow 。

將你想使用的 PDB 清單存為 nginx-pdb.yaml，然後套用到你的 AKS 叢集：

kubectl apply -f nginx-pdb.yaml

在叢集維護前，請確認每個 PDB 是否允許預期的驅逐：

kubectl get poddisruptionbudgets --namespace <namespace>

值 ALLOWED DISRUPTIONS0 可以阻擋 AKS 節點的排水。 與你的應用程式開發者和擁有者合作，維護足夠的健康副本，並選擇一個能平衡應用程式可用性與維護需求的預算。

要了解更多關於使用 Pod 中斷預算的資訊，請參閱為您的應用程式指定中斷預算。

相關內容

本文重點介紹基本的 Kubernetes 排程器功能。 欲了解更多關於 AKS 叢集作業的資訊，請參閱以下最佳實務文章：

  • 上次更新時間：