Azure Kubernetes Service (AKS) 大型工作負載效能和調整的最佳做法

  • 發行項

注意

本文的重點在於大型工作負載的一般最佳作法。 如需中小型工作負載特有的最佳作法，請參閱 Azure Kubernetes Service (AKS) 中小型工作負載效能和調整的最佳作法。

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

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

在本文中，您會了解：

  • AKS 和 Kubernetes 控制平面可擴縮性。
  • Kubernetes 用戶端最佳做法，包括輪詢、監看和分頁。
  • Azure API 和平台節流限制。
  • 功能限制。
  • 網路和節點集區調整最佳做法。

AKS 和 Kubernetes 控制平面可擴縮性

在 AKS 中，叢集是由一組執行 Kubernetes 代理程式的節點 (實體或虛擬機器 (VM)) 所組成，並由 AKS 5主控的 Kubernetes 控制平面所管理。 雖然 AKS 會針對可擴縮性和效能將 Kubernetes 控制平面及其元件最佳化，但仍受到上游專案限制的繫結。

Kubernetes 具備多維度的縮放信封，每種資源類型都代表一個維度。 並非所有資源都一樣。 例如，監看通常會在祕密上設定，這會導致對 kube-apiserver 進行清單呼叫，與沒有監看的資源相比，這會在控制平面上增加成本和不成比例的負載。

控制平面會管理叢集中的所有資源調整，因此，您在指定維度內調整叢集越多，在其他維度內需調整的就越少。 例如，在 AKS 叢集中執行數十萬個 Pod 會影響控制平面可支援的 Pod 流失率 (每秒 Pod 變動數)。

信封的大小會與 Kubernetes 控制平面的大小成正比。 AKS 支援三個控制平面階層作為基底 SKU 的一部分：免費、標準和進階層。 如需詳細資訊，請參閱 AKS 叢集管理的免費、標準和進階定價層。

重要

強烈建議您針對生產環境或大規模工作負載使用標準層或進階層。 AKS 會自動擴大 Kubernetes 控制平面，以支援下列縮放限制：

  • 每 AKS 叢集最多 5,000 個節點
  • 每 AKS 叢集有 200,000 個 Pod (使用 Azure CNI 重疊)

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

您可以利用 API 優先順序和公平性 (APF) 來節流特定的用戶端和要求類型，以在高流失和負載期間保護控制平面。

Kubernetes 用戶端

Kubernetes 用戶端是部署在 Kubernetes 叢集中的應用程式用戶端，例如運算子或監視代理程式，需與 kube-api 伺服器通訊，以執行讀取或變動作業。 請務必將這些客戶端的行為最佳化，以將它們新增至 kube-api 伺服器和 Kubernetes 控制平面的負載降到最低。

您可以透過 Kube 稽核記錄來分析 API 伺服器流量和客戶端行為。 如需詳細資訊，請參閱針對 Kubernetes 控制平面進行疑難排解。

LIST 要求的成本可能會很高。 使用可能有數千個以上小型物件或數百個以上大型物件的清單時，您應該考慮下列指導方針：

  • 在定義新的資源類型 (CRD) 時，考慮您預期最終會存在的物件數目 (CR)。
  • etcd 和 API 伺服器上的負載主要依賴存在的物件數目，而不是傳回的物件數目。 即使您使用欄位選取器來篩選清單，並只擷取少量結果，這些指導方針仍適用。 唯一的例外狀況是透過 metadata.name 擷取單一物件。
  • 如果您的程式碼需要維護記憶體中物件的更新清單，請盡量避免重複的 LIST 呼叫。 相反地，請考慮使用大多數 Kubernetes 程式庫中提供的 Informer 類別。 Informer 會自動合併 LIST 和 WATCH 功能，以有效率地維護記憶體內部集合。
  • 如果 Informer 不符合您的需求，請考慮您是否需要強式一致性。 您是否需要查看最新資料，最多到您發出查詢的確切時間？ 如果不需要，請設定 ResourceVersion=0。 這會導致 API 伺服器快取處理您的要求，而非 etcd。
  • 如果您無法使用 Informer 或 API 伺服器快取，請在 區塊中讀取大型清單。
  • 避免比需要更頻繁列出清單。 如果您無法使用 Informer，請考慮應用程式列出資源的頻率。 讀取大型清單中的最後一個物件之後，請勿立即重新查詢相同清單。 您應該稍候一段時間。
  • 考慮用戶端應用程式正在執行的執行個體數目。 讓單一控制項列出物件與讓 Pod 在每個節點上執行相同動作之間有很大的差異。 如果您打算讓用戶端應用程式的多個執行個體定期列出大量物件，您的解決方案將不會調整為大型叢集。

Azure API 和平台節流

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

若要在雲端應用程式中處理不同的負載大小，您可以允許應用程式使用多達指定限制的資源，然後在達到限制時進行節流。 在 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 診斷並解決問題來分析錯誤：您可以使用 AKS 診斷並解決問題 來分析錯誤、識別根本原因，以及取得解決建議。
  • 將叢集分割成不同的訂用帳戶或區域：如果您有大量使用虛擬機器擴展集的叢集和節點集區，您可以將其分割成不同的訂用帳戶或相同訂用帳戶內的不同區域。 大部分的 Azure API 限制都會在訂用帳戶區域層級共用，因此您可以將叢集移動或調整至不同的訂用帳戶或區域，以在 Azure API 節流上解除封鎖。 如果您預期叢集具有大量活動，此選項會特別實用。 這些限制沒有一般指導方針。 如果您想要特定指導，您可以建立支援票證。

功能限制

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

注意

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

  • Azure 網路原則管理員 (Azure npm) 最多僅支援 250 個節點。
  • 某些 AKS 節點計量，包括節點磁碟使用量、節點 CPU/記憶體使用量，以及網路進出，在調整控制平面之後，將無法在 Azure 監視器平臺計量中存取。 若要確認您的控制平面是否已相應增加，請尋找 configmap 'control-plane-scale-status'
kubectl describe configmap control-plane-scaling-status -n kube-system
  • 您無法對於擁有超過 100 個節點的叢集使用 [停止] 和 [啟動] 功能。 如需詳細資訊，請參閱停止和啟動 AKS 叢集。

網路

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

  • 針對 NAT 網路閘道上至少有兩個公用 IP 的叢集輸出使用受控 NAT。 如需詳細資訊，請參閱為 AKS 叢集建立受控 NAT 網路閘道。
  • 使用 Azure CNI 重疊來擴大至每個叢集 200,000 個 Pod 和 5,000 個節點。 如需詳細資訊，請參閱在 AKS中設定 Azure CNI 重疊網路。
  • 如果您的應用程式需要跨叢集進行直接 Pod 對 Pod 通訊，請使用具有動態 IP 配置的 Azure CNI，並為每個叢集擴大最多 50,000 個應用程式 Pod，且每個 Pod 有一個可路由傳送的 IP。 如需詳細資訊，請參閱在 AKS中設定 Azure CNI 網路以進行動態 IP 配置。
  • 在內部負載平衡器後方使用內部 Kubernetes 服務時，建議您建立規模低於 750 個節點的內部負載平衡器或服務，以獲得最佳調整效能和負載平衡器彈性。
  • Azure npm 最多僅支援 250 個節點。 如果您想要為較大的叢集強制執行網路原則，請考慮使用由 Cilium 提供的 Azure CNI，其結合了 Cilium 資料平面與 Azure CNI 強固控制平面，以提供高效能的網路和安全性。

節點集區調整

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

  • 針對系統節點集區，請使用 Standard_D16ds_v5 SKU 或具有暫時性 OS 磁碟的對等核心/記憶體 VM SKU，以便為 kube 系統 Pod 提供足夠的計算資源。
  • 由於 AKS 每個節點集區的限制為 1,000 個節點，因此建議您建立至少 5 個使用者節點集區，以擴大至 5,000 個節點。
  • 執行大規模 AKS 叢集時，請盡量使用叢集自動調整程式，以確保能根據計算資源的需求動態調整節點集區。 如需詳細資訊，請參閱自動調整 AKS 叢集以符合應用程式需求。
  • 如果您要調整超過 1,000 個節點且未使用叢集自動調整程式，建議您以批次方式一次調整 500 至 700 個節點。 調整作業在擴大作業之間應二至五分鐘的等候時間，以避免 Azure API 節流。 如需詳細資訊，請參閱 API 管理：快取和節流原則。

叢集升級考量和最佳做法

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