Azure Kubernetes Service （AKS） 大型工作負載效能與擴展的最佳實踐

在 AKS 中部署和維護叢集時，可以使用下列最佳做法來協助您將效能和調整最佳化。

請注意，大型是相對字詞。 Kubernetes 具備多維度的縮放信封，工作負載的縮放信封需取決於您所使用的資源。 例如，具備 100 個節點和數千個 Pod 或 CRD 的叢集可能會視為大型。 從控制平面的角度來看，具有 1,000 個 Pod 和各種其他資源的 1,000 個節點叢集可能會視為小型。 Kubernetes 控制面板的最佳縮放訊號是 API 伺服器 HTTP 要求成功率和延遲，因為這是控制平面負載量的 Proxy。

在本文中，您會了解：

適用於大型工作負載的 AKS 模式指引

AKS 支援兩種叢集模式：

• AKS Automatic：大多數生產工作負載的建議起點。 它透過提供可管理的平台預設值，以降低營運開銷，涵蓋擴展性、安全性、網路、監控與升級。
• AKS 標準：最適合在需要明確控制叢集拓撲、網路、自動擴展行為或升級編排時。

本文中的大規模效能與擴展指引適用於兩種叢集模式。 AKS Automatic 改變了平台預設值的擁有者，但並未消除理解控制平面負載、用戶端行為、節流、網路限制和升級餘裕的必要性。

節點縮放

當你將 AKS 叢集擴展到更大的規模點時，請牢記以下節點擴展的最佳實務：

• 在執行大規模 AKS 叢集時，盡可能使用 叢集自動擴展器 或 節點自動配置（NAP）， 以確保節點根據計算資源需求動態擴展。
• AKS Automatic 是大多數生產工作負載的建議起點，但無論是哪種叢集模式的大型叢集，仍需謹慎的節點縮放、批次規劃及控制平面驗證。
• 如果您要調整超過 1,000 個節點且未使用叢集自動調整程式，建議您以批次方式一次調整 500 至 700 個節點。 擴展操作之間應有兩到五分鐘的等待時間，以防止 Azure API 限速。
• 針對系統節點集區，請使用 Standard_D16ds_v5 SKU 或具有暫時性 OS 磁碟的對等核心/記憶體 VM SKU，以便為 kube 系統 Pod 提供足夠的計算資源。
• 由於 AKS 每個節點集區的限制為 1,000 個節點，因此建議您建立至少 5 個使用者節點集區，以擴大至 5,000 個節點。

AKS 和 Kubernetes 控制平面可擴縮性

在 Kubernetes 中，叢集中所有執行的物件都由控制平面管理，而控制平面則由 AKS 管理。 雖然 AKS 會針對可擴縮性和效能將 Kubernetes 控制平面及其元件最佳化，但仍受到上游專案限制的繫結。

這些控制平面限制與 API 使用模式同時適用於 AKS 自動版與 AKS 標準版。 AKS Automatic 可降低營運負擔，但控制平面的容量仍然有限，因此在大規模環境下，工作負載仍需以高效率的方式運作。

Kubernetes 擁有多維度的尺度範圍，每種資源類型代表一個維度，且並非所有資源的成本都相同。 例如，Secret 通常會被多個控制器和 pod 監控，每個 POD 會先呼叫一個 LIST 來同步狀態。 由於機密通常體積龐大且更新頻繁，與那些更新不頻繁的資源相比，它們會對控制層造成更多負擔。

你在某個維度內放大叢集越多，在其他維度內能縮放的次數就越少。 例如，在 AKS 叢集中執行數十萬個 Pod 會影響控制平面可支援的 Pod 流失率 (每秒 Pod 變動數)。

AKS 支援三個控制平面定價層級，作為基礎 SKU 的一部分：免費、標準與高級。 如需詳細資訊，請參閱 AKS 叢集管理的免費、標準和進階定價層。

在大部分情況下，超過調整限制閾值會導致效能降低，但不會讓叢集立即容錯移轉。 若要管理 Kubernetes 控制平面上的負載，請考慮以目前規模的最多 10 至 20% 批次進行調整。 例如，若為 5,000 個節點叢集，請以 500 至 1,000 個節點的遞增調整。 雖然 AKS 會自動調整控制平面，但不會立即調整。

要確認你的控制平面是否已經擴展，請查找 configmap large-cluster-control-plane-scaling-status。

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Kubernetes 規模上限與控制平面考量

Kubernetes 用戶端是應用程式元件，如運算元或監控代理程式，運行於叢集中，並與 kube-apiserver 通訊以讀取或修改資源。 優化這些客戶端的行為很重要，以降低它們對 kube-apiserver 和 Kubernetes 控制平面的負擔。

AKS Automatic 並不能消除有效率用戶端行為的必要性；大型叢集仍需要以監看式為基礎的模式、分頁、退避，以及有限的 LIST 流量。

API 伺服器在任何時刻積極處理的請求數量由 --max-requests-inflight 和 --max-mutating-requests-inflight 標誌決定。 AKS 對這些標誌使用預設值 400 和 200 個請求，允許在任一時間點處理總共 600 個請求。 隨著 API 伺服器規模擴大，我們也會相應增加在機內的請求數量。

兩種 Kubernetes 物件類型， PriorityLevelConfiguration 與 FlowSchema（APF），決定 API 伺服器如何將總請求容量分配至不同請求類型。 AKS 使用預設配置。

每個 PriorityLevelConfiguration 都會分配到一個總允許請求數的額度。 要查看叢集中的 PriorityLevelConfiguration 物件及其已分配的請求共享，請執行以下指令。

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

FlowSchema 將 API 伺服器請求映射到 PriorityLevelConfiguration。 若多個 FlowSchema 物件匹配同一請求，API 伺服器會選擇優先順序最低的物件。

可以使用以下指令檢視 FlowSchemas 對 PriorityLevelConfigurations 的映射：

kubectl get flowschemas

要確認是否有因 APF 而被丟棄的請求，請執行以下指令：

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Kubernetes 用戶端最佳實務

未優化用戶端發出的 LIST 呼叫，往往是限制叢集可擴展性的最大因素之一。 使用可能有數千個以上小型物件或數百個以上大型物件的清單時，您應該考慮下列指導方針：

• 在定義新的資源類型 (CRD) 時，考慮您預期最終會存在的物件數目 (CR)。
• etcd 和 API 伺服器的負載主要取決於回應的大小。 無論用戶端對大型物件發出少量 LIST 請求，或對較小物件發出大量 LIST 請求，此指引皆適用。

使用線人

• 如果程式碼需要在記憶體中保留一份更新後的物件清單，使用 client-go 程式庫中的 informer，就能直接根據事件來監看資源的變更，而不必輪詢變更。 這是避免未優化且重複的 LIST 的最佳方法。

使用 API 伺服器快取

用 resourceVersion=0 來回傳 API 伺服器快取的結果。 這可以防止物件從 etcd 抓取，從而降低 etcd 負載，但不支援分頁。

/api/v1/namespaces/default/pods?resourceVersion=0

Kubernetes API 的高效使用

建議盡可能使用監控引數。 沒有參數時，預設行為是列出物件。 例如：

/api/v1/namespaces/default/pods?watch=true

使用監控時，請將resourceVersion設定為先前列表或監控時所收到的最新已知值。 這在 client-go 中會自動處理。 但請確認你是否使用其他語言的 Kubernetes 客戶端。

/api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>

如果控制器或運算子必須使用 LIST 呼叫，則應避免在沒有標籤或欄位選取器的情況下輪詢叢集範圍內的資源，特別是在大型叢集中。 以下範例展示了優化與未優化的 LIST 呼叫。

• 優化清單：

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running
  

• 未最佳化清單：

  /api/v1/pods
  

如果用戶端必須從 etcd 擷取資料，使用分頁來減少 LIST 回應的大小。 以下範例使用限制參數來限制回應數為 100 個物件。

/api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100

如果你想讓 LIST 繼續回傳上述範例中所有 pod 物件，請使用 extend 參數並限制。

/api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>

如果使用 kubectl， --chunk-size 論證可以直接應用於分頁回應。

kubectl get pods -n default --chunk-size=100

如果你的控制器或操作員使用租約更新來選擇領導者，請確保它們能夠耐受短暫的連線問題，藉由調整 leaseDuration、renewDeadline 和 retryPeriod 來符合適合您的工作負載的最佳參數。 對於使用 client-go 領導者選舉的 Kubernetes 控制器，請使用以下公式：

lease_duration > renew_deadline > retry_period

Daemonset

• 單一控制器列出物件，與在每個節點上執行相同操作的 DaemonSet 有顯著差異。 如果多個客戶端應用程式週期性地列出大量物件，解決方案在大型叢集中無法良好擴展。

• 在擁有數千節點的叢集中，建立新的守護程序集、更新守護程序集或增加節點數量，都可能導致控制平面負載過高。 如果 DaemonSet pod 在啟動時發出昂貴的 API 伺服器請求，可能會因大量同時請求而導致控制平面上的資源消耗大幅增加。

• 使用 RollingUpdate 策略逐步更新新的 DaemonSet Pod。 當 DaemonSet 模板更新時，控制器會以受控的方式替換舊的 pod 為新的。 當滾動更新策略未明確設定時，Kubernetes 會預設建立一個 RollingUpdate，將 maxUnavailable 設為 1，maxSurge 為 0，minReadySeconds 為 0。 請參考以下範例。

    minReadySeconds: 30
    updateStrategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 0
        maxUnavailable: 1
  

• RollingUpdate 策略只適用於現有的 DaemonSet Pods。 它不會限制新增節點（產生額外 DaemonSet Pod）或部署全新 DaemonSet 的影響。

• 為防止 DaemonSets 在節點擴展或新 DaemonSet 部署後啟動時同時向 API 伺服器發出 LIST 請求，請在容器入口點實作啟動抖動，並針對 5xx 或 429 回應設定適當的 指數退換 與 重試策略 ，以防止大型 LIST 請求重複重試。

    spec:
      template:
        spec:
          containers:
          - name: my-daemonset-container
            image: <image>
            command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]
  

etcd 優化

• 保持 etcd 的整體大小較小，不要把 etcd 當作通用資料庫使用。 AKS 預設提供 8 GB 的 etcd 儲存空間，但較大的 etcd 資料庫會增加重組時間，可能導致讀寫效能問題。 較大的 etcd 資料庫也可能增加 API 伺服器與 etcd 可靠性問題的機率，若未優化的用戶端頻繁從 etcd 擷取大量物件。 如果你的 etcd 資料庫大小超過 2 GB，請考慮使用以下列出的物件大小縮小技巧。
• 若要減少 Pod 規格大小，請將環境變數從 Pod 規格移至 ConfigMaps。
• 將大型秘密或 ConfigMap 分割成更小、更易於管理的部分。
• 請盡可能將秘密儲存在 Azure Key Vault 中，而非使用 Kubernetes Secret，以減少儲存在 etcd 中的秘密數量。
• 清理未使用的物品
  • 刪除過期的 Job 和已完成的 Pod。 在工作任務上使用 ttlSecondsAfterFinished，這樣完成的物件能夠被自動移除。
  • 確保控制器已設定 ownerReferences。 這使得 Kubernetes 垃圾回收能在父資源被刪除時自動移除相依物件。
  • 透過設定 successfulJobsHistoryLimit 和 failedJobsHistoryLimit 來限制 CronJob 歷史，只保留少數已完成的工作紀錄。
  • 簡化部署展開歷史。 舊的 ReplicaSets 也會以 API 物件形式儲存。 預設值為 10。
• 用這個 --history-max 論點減少 Helm 的修訂歷史。 在大型群組中，保持在5以下。

監控 AKS 控制平面的指標與日誌

監視大型 AKS 叢集中的控制平面計量，對於確保 Kubernetes 工作負載的穩定性和效能至關重要。 這些計量可讓您查看重要元件的健康情況和行為，例如 API 伺服器、etcd、控制器管理員和排程器。 在大規模環境中，資源競爭和高 API 呼叫量很常見。監視控制平面計量有助於識別瓶頸、偵測異常狀況，使資源使用狀況達到最佳化。 藉由分析這些計量，操作員可以主動解決 API 伺服器延遲、高 etcd 物件或控制平面資源使用量過多等問題，提高叢集作業的效率，將停機時間降到最低。

AKS Automatic 可降低維運負擔，但在工作負載規模較大時，您仍需要對控制平面健康狀況、請求延遲和 etcd 壓力具備同等的可觀測性。

Azure 監視器透過 Azure 管控的 Prometheus 和診斷設定，提供控制平面上有關健康的完整指標與紀錄。

• 如需設定控制平面健康狀態的警示清單，請參閱 AKS 控制平面監控的最佳實務
• 要取得延遲最高的使用者代理列表，可以使用 控制平面日誌/診斷設定

主要控制平面平台指標

AKS 在 Azure 監視器 中暴露以下平台指標，用於監控 API、伺服器及 etcd 健康狀況。 這些指標可在未啟用 Managed Prometheus 的情況下取得，並可直接在 Azure 入口網站的 Metrics 下查看，適用於你的 AKS 叢集。

API 伺服器指標：

ETCHD 指標：

持續監控 apiserver_cpu_usage_percentage 並 apiserver_memory_usage_percentage 偵測 API 伺服器上的資源壓力。 如果 etcd_database_usage_percentage 持續超過 50%， 請檢視 Etcd 優化 部分以減少資料庫大小。 欲了解完整可用指標清單，請參閱 AKS 監控資料參考。

功能限制

當您將 AKS 叢集調整為較大的縮放點時，請記住下列功能限制：

• 根據預設，AKS 支援所有標準層 / LTS 叢集最多擴充為 5,000 個節點。 AKS 會根據叢集大小和 API 伺服器資源使用率，在執行階段調整叢集的控制平面。 如果你無法擴展到支援的限制，請啟用 控制平面的指標 (預覽)，並使用 適用於 Prometheus 的 Azure 監視器 管理服務 來監控控制平面。 為了協助排除擴展效能或可靠性問題，請參考以下資源：

  • 大規模 AKS 疑難排解指南
  • 針對 Kubernetes 控制平面進行疑難排解

  附註

  在調整控制平面的作業期間，您可能遇到提升的 API 伺服器延遲或逾時，最多 15 分鐘。 如果您繼續發生調整為支援限制的問題，請開啟支援票證。

• Azure 網路政策管理器（Azure npm） 僅支援最多 250 個節點。

• 部分 AKS 節點指標，包括節點磁碟使用率、節點 CPU/記憶體使用率及網路進出，在控制平面擴展後，將無法在 Azure 監控平台指標中存取。

• 您無法對於擁有超過 100 個節點的叢集使用 [停止] 和 [啟動] 功能。 如需詳細資訊，請參閱停止和啟動 AKS 叢集。

Azure API 與平台節流限制

雲端應用程式上的負載可能會隨著時間而有所不同，取決於活躍使用者的數目或使用者執行的動作類型。 如果系統的處理需求超過可用資源的容量，系統可能會過載，且變得效能不佳和失敗。

AKS Automatic 簡化了叢集操作，但 Azure 訂閱與平台限速限制在大規模時仍然適用。

若要在雲端應用程式中處理不同的負載大小，您可以允許應用程式使用多達指定限制的資源，然後在達到限制時進行節流。 在 Azure 上，節流會在兩個層級發生。 Azure Resource Manager （ARM）會限制訂閱和租戶的請求流量。 如果要求在訂用帳戶和租用戶的節流限制下，ARM 會將要求路由至資源提供者。 然後，資源提供者會套用針對其作業量身訂做的節流限制。 如需詳細資訊，請參閱 ARM 節流要求。

管理 AKS 中的節流

Azure API 的限制通常是在訂閱與區域組合層級定義的。 例如，同一區域內訂閱內的所有用戶端都會共享 Azure API 的 API 限制，例如 虛擬機器擴展集 PUT API。 每個 AKS 叢集都有多個 AKS 擁有的用戶端，例如雲端服務提供者或叢集自動擴展器，或客戶擁有的用戶端，如 Datadog 或自架 Prometheus，這些用戶端會呼叫 Azure API。 在指定區域內的訂用帳戶中執行多個 AKS 叢集時，叢集中所有 AKS 擁有和客戶擁有的用戶端都會共用一組常見的 API 限制。 因此，您可以在訂用帳戶區域中部署的叢集數目是已部署的用戶端數目、其呼叫模式以及叢集整體規模和彈性的函數。

請記住上述考慮，客戶通常能夠在每個訂用帳戶區域部署 20 至 40 個中小型叢集。 您可以使用下列最佳做法將訂用帳戶規模最大化：

一律將您的 Kubernetes 叢集升級至最新版本。 較新版本包含許多改善內容，可解決效能和節流問題。 如果您使用升級的 Kubernetes 版本，但仍會因為實際負載或訂用帳戶中的用戶端數目而看到節流情形，您可以嘗試下列選項：

• 使用 AKS Diagnose and Solve Problems 分析錯誤：你可以使用 AKS Diagnose and Solve Problems 來分析錯誤、找出根本原因，並獲得解決建議。
  • 增加叢集自動調整器掃描間隔：若診斷報告顯示偵測到叢集自動調整器節流，您可以延長掃描間隔以減少叢集自動調整器撥虛擬機器擴展集的通話次數。
  • 重新設定第三方應用程式以發出較少的呼叫：如果您在檢視要求率和節流詳細資料診斷中以使用者代理程式進行篩選，並發現第三方應用程式 (例如監視應用程式) 進行大量的 GET 要求，您可以變更這些應用程式的設定，以減少 GET 呼叫的頻率。 確保應用程式客戶端在呼叫 Azure API 時使用指數退換。
• 將叢集拆分成不同的訂閱或區域：如果你有大量叢集和節點池使用 虛擬機器擴展集，可以將它們拆分成同一訂閱內的不同訂閱或區域。 大多數 Azure API 的限制是在訂閱區級共享的，所以你可以將叢集移動或擴展到不同的訂閱或區域，以解除 Azure API 限速的阻擋。 如果您預期叢集具有大量活動，此選項會特別實用。 這些限制沒有一般指導方針。 如果您想要特定指導，您可以建立支援票證。

網路

當您將 AKS 叢集調整為較大的縮放點時，請記住下列網路最佳做法：

• 針對 NAT 網路閘道上至少有兩個公用 IP 的叢集輸出使用受控 NAT。 如需詳細資訊，請參閱為 AKS 叢集建立受控 NAT 網路閘道。

• AKS Automatic 提供管理網路預設值，但在擴展大型工作負載時，仍應驗證出站路徑、DNS 行為、負載平衡限制及服務拓撲。

• 如果你用的是 Azure Standard Load Balancer，至少要用2 個出站公共 IP 位址。 在規劃大型叢集時，也要考慮 LoadBalancer 服務後端的規則限制。 Azure 標準負載平衡器支援每個前端 IP 最多 10,000 個後端 IP 配置。 每種類型：LoadBalancer 服務為每個暴露埠建立一條負載平衡規則，並將所有叢集節點與負載平衡器後端池關聯。 例如，為單一服務暴露 5 個埠口，會在 2000 節點時達到這個限制。

  1 service * 5 ports * 2000 nodes = 10000 backend IP configurations
  

• 使用 Azure CNI Overlay 可擴展至 200,000 個 pod 和每個叢集 5,000 個節點。 欲了解更多資訊，請參閱 Configure Azure CNI Overlay networking in AKS。

• 如果你的應用程式需要跨叢集直接 pod 對 pod 通訊，使用 Azure CNI 搭配動態 IP 分配，並以一個可路由的 IP 擴展到每個叢集最多 50,000 個應用程式 Pod。 欲了解更多資訊，請參閱 在 AKS 中配置 Azure CNI 網路以動態分配 IP 位址。

• 在內部負載平衡器後方使用內部 Kubernetes 服務時，建議您建立規模低於 750 個節點的內部負載平衡器或服務，以獲得最佳調整效能和負載平衡器彈性。

• Azure 網路政策管理器（NPM）最多只支援 250 個節點。 若想為大型叢集執行網路政策，可考慮使用 Cilium Azure CNI，結合 Azure CNI 穩健的控制平面與 Cilium 資料平面，提供高效能網路與安全性。

• 在節點池啟用 LocalDNS ，以降低 DNS 解析延遲並卸載集中式的 CoreDNS Pods。 在擁有大量 DNS 查詢量的大型叢集中，集中式 DNS 解析可能成為瓶頸。 LocalDNS 在每個節點部署 DNS 代理作為 systemd 服務，本地解決查詢，消除 conntrack 資料表壓力，並將連線升級為 TCP 以避免 conntrack 競賽狀態。 LocalDNS 也支援在上游 DNS 無法使用時提供過時的快取回應，提升工作負載在短暫故障時的韌性。 欲了解更多資訊，請參閱 AKS 中的 DNS 解析。

叢集升級考量和最佳做法

AKS Automatic 可為您處理升級生命週期中更多環節，但本節關於最大擴增和容量規劃的指引，對大型工作負載仍然很重要，尤其是在協調中斷作業並確保有足夠的容量餘裕時。

當你將 AKS 叢集擴展到更大的規模點時，請牢記以下叢集升級的最佳實務：

• 當叢集達到 5,000 個節點限制時，就會封鎖叢集升級。 這個限制阻止升級，因為節點容量無法在最大突波屬性限制內執行滾動更新。 如果您的叢集有此限制，建議您在嘗試升級叢集之前，先將叢集縮小為 3,000 個節點以下。 這會為節點變換提供額外的容量，並將控制平面的負載降到最低。
• 升級超過 500 個節點的叢集時，建議使用節點池容量 10-20% 的最大 突波配置 。 AKS 會針對最大激增設定預設值為 10% 的升級。 您可以自訂每個節點集區的最大激增設定，以在升級速度和工作負載中斷之間取捨。 您增加最大激增設定時，升級程式會更快完成，但您可能會在升級程式期間遇到中斷。 如需詳細資訊，請參閱自訂節點激增升級。
• 如需更多叢集升級資訊，請參閱升級 AKS 叢集。

相關內容

• 什麼是 AKS Automatic？
• Azure Kubernetes Service （AKS） 中小型至中型工作負載的性能與擴展最佳實踐