Share via

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

  • 發行項

注意

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

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

在本文中，您會了解：

  • 自動調整工作負載的權衡取捨和建議。
  • 根據工作負載需求來管理節點調整和效率。
  • 輸入和輸出流量的網路考量。
  • 監視控制平面和節點效能並對其進行疑難排解。
  • 容量規劃、激增情節及叢集升級。
  • 資料平面效能的儲存和網路考量。

比較應用程式自動調整與基礎結構自動調整

應用程式自動調整

處理成本最佳化或基礎結構限制時，應用程式自動調整非常有用。 妥善設定的自動調整程式可維持應用程式的高可用性，同時將成本降至最低。 無論需求為何，您只需支付維持可用性所需的資源費用。

例如，若現有的節點有空間，但子網路中沒有足夠的 IP，系統可能會略過建立新節點，改為立即在新 Pod 上開始執行應用程式。

水平 Pod 自動調整

對於資源需求穩定且可預測的應用程式來說，實作水平 Pod 自動調整非常有用。 水平 Pod 自動調整程式 (HPA) 可動態調整 Pod 複本數目，有效地將負載散發到多個 Pod 和節點。 這個調整機制對於可分解為能夠平行執行之較小獨立元件的應用程式通常最有幫助。

HPA 預設會提供資源使用率計量。 您也可以整合自訂計量，或利用 Kubernetes 事件驅動自動調整程式 (KEDA) (預覽版) 等工具。 這些延伸模組可讓 HPA 根據多種視角和準則做出調整決策，以提供更全面的應用程式效能檢視。 這特別適用於具有不同複雜調整需求的應用程式。

注意

如果維持應用程式的高可用性是重中之重，建議您針對 HPA 的最小 Pod 數目留出略高一點的緩衝區，將調整時間納入考量。

垂直 Pod 自動調整

對於資源需求有波動且無法預測的應用程式來說，實作垂直 Pod 自動調整非常有用。 垂直 Pod 自動調整程式 (VPA) 可讓您微調個別 Pod 的資源要求 (包括 CPU 和記憶體)，以精確控制資源配置。 這種細微性可將資源浪費降至最低，並提升叢集的整體使用效率。 VPA 還會透過自動化資源配置、為重要工作釋出資源，以簡化應用程式管理。

警告

您不應該在相同的 CPU 或記憶體計量上同時使用 VPA 與 HPA。 這種組合可能會導致衝突，因為兩個自動調整程式都會嘗試使用相同的計量來回應需求變化。 不過，您可以將 VPA 用於 CPU 或記憶體並將 HPA 用於自訂計量，以防止重疊，並確保每個自動調整程式著重於工作負載調整的不同層面。

注意

VPA 會根據歷程記錄資料運作。 建議您在部署 VPA 之後至少等候 24 小時 再套用任何變更，使其有足夠的時間收集建議的資料。

基礎結構自動調整

叢集自動調整

如果現有的節點沒有足夠的容量，實作叢集自動調整就很有用，因為這有助於擴大和佈建新的節點。

考慮使用叢集自動調整時，何時移除節點的決定牽涉到最佳化資源使用率與確保資源可用性之間的權衡取捨。 排除使用量過低的節點可提高叢集使用率，但可能會導致新的工作負載必須等到資源佈建完成後才能進行部署。 請務必在這兩個因素之間找出符合叢集與工作負載需求的平衡，並據以設定叢集自動調整程式設定檔設定。

叢集自動調整程式設定檔設定普遍套用至叢集中所有已啟用自動調整程式的節點集區。 這表示在一個已啟用自動調整程式的節點集區中發生任何調整動作，都可能會影響另一個節點集區中的自動調整行為。 請務必在所有相關節點集區中套用一致且同步的設定檔設定，以確保自動調整程式如預期般運作。

過度佈建

超額佈建是一種策略，藉由確保有超額的可用資源，協助降低應用程式壓力的風險。 這種方法特別適用於負載變化很大，以及叢集調整模式頻繁擴大和縮小的應用程式。

若要判定最佳的超額佈建數量，您可以使用下列公式：

1-buffer/1+traffic

例如，假設您想要避免在叢集中達到 100% 的 CPU 使用率。 您可以選擇 30% 的緩衝區來維持安全邊界。 如果預期平均流量增長率為 40%，您可能會考慮超額佈建 50%，如公式計算：

1-30%/1+40%=50%

有效的超額佈建方法牽涉到使用「暫停 Pod」。 暫停 Pod 是低優先順序部署，可輕易地由高優先順序部署取代。 您可以建立低優先順序 Pod，其唯一目的是保留緩衝區空間。 當高優先順序 Pod 需要空間時，系統會移除暫停 Pod，並將其重新排程在另一個節點或新節點上，以容納高優先順序 Pod。

下列 YAML 顯示暫停 Pod 資訊清單範例：

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi

節點調整和效率

最佳做法指導方針：

仔細監視資源使用率和排程原則，以確保有效率地使用節點。

節點調整可讓您根據工作負載需求動態調整叢集中的節點數目。 請務必了解，將更多節點新增至叢集不一定是提高效能的最佳解決方案。 為了確保最佳效能，您應該仔細監視資源使用率和排程原則，以確保有效率地使用節點。

節點映像

最佳做法指導方針：

使用最新的節點映像版本，以確保您有最新的安全性修補程式和 Bug 修正。

使用最新的節點映像版本可提供最佳的效能體驗。 AKS 會在每週映像版本內提供效能改進。 最新的精靈集映像會快取在最新的 VHD 映像上，這可為節點佈建與啟動提供延遲較低的優點。 更新落後可能會對效能造成負面影響，因此請務必避免版本之間存在較大差距。

Azure Linux

AKS 上的 Azure Linux 容器主機會使用原生 AKS 映像，並為 Linux 開發提供單一位置。 每個套件都是從來源建置並經過驗證，確保您的服務在經過實證的元件上執行。

Azure Linux 是輕量型軟體，只包含執行容器工作負載所需的套件組。 其提供縮減的攻擊面，並消除不必要套件的修補和維護。 在 Azure Linux 的基礎層中，有針對 Azure 調整的 Microsoft 強化核心。 此映像適用於效能感應式工作負載以及管理 AKS 叢集群的平台工程師或操作員。

Ubuntu 2204

Ubuntu 2204 映像 (英文) 是 AKS 的預設節點映像。 該映像是為了執行容器化工作負載而最佳化的輕量型高效操作系統。 這表示其可協助減少資源使用量並提高整體效能。 該映像包含最新的安全性修補程式和更新，有助於確保工作負載免於遭受弱點攻擊。

Microsoft、Canonical 和 Ubuntu 社群完全支援 Ubuntu 2204 映像，可協助您提高容器化工作負載的效能和安全性。

虛擬機器 (VM)

最佳做法指導方針：

選取 VM 時，請確定 OS 磁碟與 VM SKU 的大小和效能沒有太大的差異。 大小或效能的差異可能會導致效能問題和資源競爭。

應用程式效能與您在工作負載中使用的 VM SKU 密切相關。 較大型且功能更強大的 VM，其效能通常會更好。 對於「任務關鍵性工作負載或產品工作負載」，建議您使用至少具有 8 核心 CPU 的 VM。 硬體世代較新 (例如 v4 和 v5) 的 VM 也有助於提高效能。 請記住，建立與調整延遲可能因使用的 VM SKU 而有所不同。

使用專用的系統節點集區

為了調整效能和可靠性，建議您使用專用的系統節點集區。 使用此組態時，專用的系統節點集區會為系統 OS 精靈等重要系統資源保留空間。 然後，應用程式工作負載就可以在使用者節點集區中執行，以增加應用程式可配置資源的可用性。 此組態還有助於降低系統與應用程式之間的資源競爭風險。

建立作業

檢閱您已在建立佈建期間啟用的延伸模組和附加元件。 延伸模組和附加元件可能會增加建立作業的整體持續時間延遲。 如果不需要延伸模組或附加元件，建議您將其移除以降低建立延遲。

您也可以使用可用性區域來提供較高層級的可用性，以防止潛在的硬體故障或計劃性維護事件。 AKS 叢集會將資源散發到底層 Azure 基礎結構的邏輯區段。 可用性區域實際上將節點與其他節點分開，以協助確保單一失敗不會影響應用程式的可用性。 可用性區域僅適用於特定區域。 如需詳細資訊，請參閱 Azure 中的可用性區域。

Kubernetes API 伺服器

LIST 和 WATCH 作業

Kubernetes 會使用 LIST 和 WATCH 作業與 Kubernetes API 伺服器互動，並監視叢集資源的相關資訊。 這些作業是 Kubernetes 如何執行資源管理的基礎。

LIST 作業會擷取符合特定準則的資源清單，例如特定命名空間中的所有 Pod 或叢集中的所有服務。 如果想要取得叢集資源的概觀，或需要一次操作多個資源時，這項作業很有用。

LIST 作業可以擷取大量資料，特別是在擁有多個資源的大型叢集中。 請注意，無限制或頻繁地進行 LIST 呼叫會對 API 伺服器造成大量負載，而且可以關閉回應時間。

WATCH 作業會執行即時資源監視。 當您在資源上設定 WATCH 時，只要該資源發生變更，API 伺服器就會傳送更新。 這對於控制器而言很重要，例如依賴 WATCH 來維護所需資源狀態的 ReplicaSet 控制器。

請注意，監看太多可變資源或發出太多並行 WATCH 要求可能會使 API 伺服器不堪重負，並導致資源耗用過多。

若要避免潛在問題，並確保 Kubernetes 控制平面的穩定性，您可以使用下列策略：

資源配額

實作資源配額，限制特定使用者或命名空間可列出或監看的資源數目，以防止呼叫過多。

API 優先順序和公平性

Kubernetes 引入了 API 優先順序和公平性 (APF) 的概念，以設定和管理 API 要求的優先順序。 您可以在 Kubernetes 中使用 APF 來保護叢集的 API 伺服器，並減少用戶端應用程式看到的 HTTP 429 Too Many Requests 回應數目。

自訂資源 主要功能
PriorityLevelConfigurations • 為 API 要求定義不同的優先順序層級。
• 指定唯一的名稱，並指派代表優先順序層級的整數值。 優先順序層級越高，整數值越低，表示這些層級更為重要。
• 可使用多個，根據要求的重要性，將要求分類為不同的優先順序層級。
• 可讓您指定特定優先順序層級的要求是否應受限於速率限制。
FlowSchemas • 定義應如何根據要求屬性將 API 要求路由傳送至不同的優先順序層級。
• 根據 API 群組、版本和資源等準則指定符合要求的規則。
• 當要求符合指定規則時，要求會導向至相關聯 PriorityLevelConfiguration 中指定的優先順序層級。
• 當多個 FlowSchemas 符合要求時，可用來設定評估順序，以確保特定規則的優先順序較高。

使用 PriorityLevelConfigurations 和 FlowSchemas 設定 API 可讓重要 API 要求的優先順序高於較不重要的要求。 這可確保基本作業不會因為優先順序較低的要求而缺乏資源或遇到延遲。

最佳化標籤和選取器

使用 LIST 作業時，將標籤選取器最佳化來縮小您想要查詢的資源範圍，以減少傳回的資料量和 API 伺服器上的負載。

在 Kubernetes 中，CREATE 和 UPDATE 作業是指管理及修改叢集資源的動作。

CREATE 和 UPDATE 作業

CREATE 作業可在 Kubernetes 叢集中建立新的資源，例如 Pod、服務、部署、configmap 和秘密。 在 CREATE 作業期間，kubectl 或控制器等用戶端會將要求傳送至 Kubernetes API 伺服器以建立新資源。 API 伺服器會驗證要求、確保符合任何許可控制器原則，然後在叢集所需的狀態下建立資源。

UPDATE 作業可修改 Kubernetes 叢集中的現有資源，包括資源規格的變更，例如複本數目、容器映像、環境變數或標籤。 在 UPDATE 作業期間，用戶端會將要求傳送至 API 伺服器，以更新現有的資源。 API 伺服器會驗證要求、將變更套用至資源定義，以及更新叢集資源。

CREATE 和 UPDATE 作業在下列情況下可能會影響 Kubernetes API 伺服器的效能：

  • 高度並行：當多個使用者或應用程式提出並行的 CREATE 或 UPDATE 要求時，可能會導致同時抵達伺服器的 API 要求激增。 這可能會對 API 伺服器的處理容量造成壓力，並導致效能問題。
  • 資源定義複雜：過於複雜或牽涉到多個巢狀物件的資源定義會增加 API 伺服器驗證和處理 CREATE 和 UPDATE 要求所需的時間，這可能會導致效能降低。
  • 資源驗證和許可控制：Kubernetes 會對傳入的 CREATE 和 UPDATE 要求強制執行各種許可控制原則和驗證檢查。 大型資源定義 (如具有大量註釋或組態的資源定義) 可能需要更多的處理時間。
  • 自訂控制器：監視資源變更的自訂控制器 (如 Deployments 或 StatefulSet 控制器) 可能會在調整或推出變更時產生大量更新。 這些更新可能會造成 API 伺服器資源緊張。

如需詳細資訊，請參閱針對 AKS 中的 API 伺服器和 etcd 問題進行疑難排解。

資料平面效能

Kubernetes 資料平面負責管理容器與服務之間的網路流量。 資料平面的問題可能會導致回應時間變慢、效能降低，以及應用程式停機。 請務必仔細監視資料平面組態 (例如網路延遲、資源配置、容器密度和網路原則) 並將其最佳化，以確保容器化應用程式能夠順暢且有效率地執行。

儲存體類型

AKS 建議並預設使用暫時性 OS 磁碟。 暫時性 OS 磁碟會在本機 VM 儲存體上建立，不會儲存於遠端 Azure 儲存體 (如受控 OS 磁碟)。 這些磁碟可縮短重新映像和開機時間、加快叢集作業速度，以及在 AKS 代理程式節點的 OS 磁碟上提供較低的讀取/寫入延遲。 暫時性 OS 磁碟適合無狀態工作負載，其中的應用程式可容忍個別 VM 失敗，但不能容忍 VM 部署時間或個別 VM 重新映像執行個體。 只有特定 VM SKU 支援暫時性 OS 磁碟，因此您必須確保所需的 SKU 世代和大小相容。 如需詳細資訊，請參閱 Azure Kubernetes Service (AKS) 中的暫時性 OS 磁碟。

如果工作負載無法使用暫時性 OS 磁碟，AKS 預設為使用進階 SSD OS 磁碟。 如果進階 SSD OS 磁碟與工作負載不相容，AKS 預設為使用標準 SSD 磁碟。 目前，唯一可用的其他 OS 磁碟類型是標準 HDD。 如需詳細資訊，請參閱 Azure Kubernetes Service (AKS) 中的儲存體選項。

下表提供 AKS 所支援之 OS 磁碟的建議使用案例明細：

OS 磁碟類型 主要功能 建議的使用案例
暫時 OS 磁碟 • 重新映像時間和開機時間更快。
• AKS 代理程式節點 OS 磁碟上的讀取/寫入延遲較低。
• 高效能和高可用性。		 • 需求較高的企業工作負載，例如 SQL Server、Oracle、Dynamics、Exchange Server、MySQL、Cassandra、MongoDB、SAP Business Suite 等。
• 需要高可用性和低延遲的無狀態生產工作負載。
進階 SSD OS 磁碟 • 效能一致且延遲較低。
• 高可用性。		 • 需求較高的企業工作負載，例如 SQL Server、Oracle、Dynamics、Exchange Server、MySQL、Cassandra、MongoDB、SAP Business Suite 等。
• 輸入/輸出 (IO) 密集型企業工作負載。
標準 SSD OS 磁碟 • 效能一致。
• 相較於標準 HDD 磁碟，可用性和延遲更佳。		 • Web 伺服器。
• 每秒輸入/輸出作業數 (IOPS) 很低的應用程式伺服器。
• 輕度使用的企業應用程式。
• 開發/測試工作負載。
標準 HDD 磁碟 • 成本低。
• 效能和延遲呈現變化。		 • 備份儲存體。
• 不常存取的大量儲存體。

IOPS 和輸送量

每秒的輸入/輸出作業數 (IOPS) 是指磁碟每秒可執行的讀取和寫入作業數目。 輸送量是指可在指定時段內傳輸的資料量。

OS 磁碟負責儲存作業系統及其相關聯的檔案，而 VM 則負責執行應用程式。 選取 VM 時，請確定 OS 磁碟與 VM SKU 的大小和效能沒有太大的差異。 大小或效能的差異可能會導致效能問題和資源競爭。 例如，若 OS 磁碟明顯小於 VM，則可能會限制應用程式資料可用的空間量，並導致系統耗盡磁碟空間。 如果 OS 磁碟的效能低於 VM，其可能會成為瓶頸，並限制系統的整體效能。 請確定大小和效能平衡，以確保 Kubernetes 的效能最佳。

您可以使用下列步驟在 Azure 入口網站中監視 OS 磁碟上的 IOPS 和頻寬計量：

  1. 瀏覽至 Azure 入口網站。
  2. 搜尋 [虛擬機器擴展集]，然後選取您的虛擬機器擴展集。
  3. 在 [監視] 下，選取 [計量]。

暫時性 OS 磁碟可以為應用程式提供動態 IOPS 和輸送量，而受控磁碟的 IOPS 和輸送量則有上限。 如需詳細資訊，請參閱 Azure VM 的暫時性 OS 磁碟。

Azure 進階 SSD v2 專為需要亞毫秒磁碟延遲、高 IOPS 與輸送量且低成本的 IO 密集型企業工作負載所設計。 其適用於各種不同的工作負載，例如 SQL Server、Oracle、MariaDB、SAP、Cassandra、MongoDB、巨量資料/分析、遊戲等等。 此磁碟類型是目前可用於永續性磁碟區的最高效能選項。

Pod 排程

配置給 VM 的記憶體和 CPU 資源會直接影響 VM 上執行的 Pod 效能。 建立 Pod 時，系統會為其指派一定數量的記憶體和 CPU 資源，以用來執行應用程式。 如果 VM 沒有足夠的記憶體或 CPU 資源可用，則可能會導致 Pod 變慢，甚至當機。 如果 VM 有太多可用的記憶體或 CPU 資源，可能會導致 Pod 執行效率不佳、浪費資源並增加成本。 建議您針對可配置的資源總數監視工作負載中的 Pod 要求總數，以獲得最佳的排程可預測性和效能。 您也可以使用 --max-pods，根據容量規劃來設定每個節點的 Pod 數目上限。