共用方式為

Azure 架構良好的架構檢閱 - Azure Kubernetes Service （AKS）

  • 發行項

本文提供 Azure Kubernetes Service （AKS） 的架構最佳做法。 此指引是以架構卓越五大要素為基礎：

  • 可靠性
  • 安全性
  • 成本最佳化
  • 卓越營運
  • 效能效益

我們假設您了解系統設計原則、具備 Azure Kubernetes Service 的工作知識，並熟悉其功能。 如需詳細資訊，請參閱 Azure Kubernetes Service。

必要條件

了解架構完善的架構支柱有助於產生高品質、穩定且有效率的雲端架構。 建議您使用 Azure 架構良好的架構檢閱 評估來檢閱您的工作負載。

針對內容，請考慮檢閱參考架構，以反映其設計中的這些考慮。 建議您從 Azure Kubernetes Service （AKS） 叢集和 Azure Kubernetes Service 上的微服務架構基準架構開始。 另請檢閱 AKS 登陸區域加速器，其提供架構方法和參考實作，為可調整的 Azure Kubernetes Service （AKS） 叢集準備登陸區域訂用帳戶。

可靠性

在雲端中，我們知道失敗在所難免。 此目標不是試著完全避免失敗，而是將單一故障元件的影響降至最低。 使用下列資訊將失敗的實例降到最低。

使用 Azure Kubernetes Service 討論可靠性時，請務必區分叢集可靠性和工作負載可靠性。 叢集可靠性是叢集管理員與其資源提供者之間的共同責任，而工作負載可靠性是開發人員的網域。 Azure Kubernetes Service 對這兩個角色有所考量和建議。

在 下列設計檢查清單 和建議 清單中 ，會發出圖說文字來指出每個選擇是否適用於叢集架構、工作負載架構或兩者。

設計檢查清單

  • 叢集架構： 針對重要工作負載，請使用 AKS 叢集的可用性區域 。
  • 叢集架構： 規劃IP位址空間，以確保叢集能夠可靠地調整，包括處理多重叢集拓撲中的故障轉移流量。
  • 叢集架構： 檢閱 使用 Azure 監視器 監視 Kubernetes 的最佳做法，以判斷工作負載的最佳監視策略。
  • 工作負載架構： 確定已建置工作負載以支援水平調整和報告應用程式整備程度和健康情況。
  • 叢集和工作負載架構： 確定您的工作負載正在用戶節點集區上執行，並選擇正確的大小 SKU。 至少包含使用者節點集區的兩個節點，以及系統節點集區的三個節點。
  • 叢集架構： 使用 AKS 運行時間 SLA 來符合生產工作負載的可用性目標。

AKS 設定建議

探索下表的建議，以將 AKS 設定優化為可靠性。

建議 優點
叢集和工作負載架構： 使用節點選取器和親和性來控制 Pod 排程。 允許 Kubernetes 排程器以邏輯方式隔離節點中的硬體工作負載。 與 容忍不同，沒有相符節點選取器的 Pod 可以在已標記的節點上排程，這可讓節點上未使用的資源取用，但優先於定義相符節點選取器的 Pod。 使用節點親和性以取得更大的彈性，這可讓您定義Pod無法與節點相符時會發生什麼情況。
叢集架構： 確保根據網路需求和叢集大小適當選擇網路外掛程式。 特定案例需要 Azure CNI，例如 Windows 型節點集區、特定網路需求和 Kubernetes 網路原則。 如需詳細資訊，請參閱 Kubenet 與 Azure CNI 。
叢集和工作負載架構： 針對生產等級叢集使用 AKS 運行時間 SLA 。 AKS 執行時間 SLA 保證：
- 99.95%適用於使用 Azure 可用性區域 的 AKS 叢集 Kubernetes API 伺服器端點可用性，或
- 99.9%未使用 Azure 可用性區域 的 AKS 叢集可用性。
叢集和工作負載架構： 檢閱 使用 Azure 監視器 監視 Kubernetes 的最佳做法，以判斷工作負載的最佳監視策略。 N/A
叢集架構： 使用 可用性區域 ，將 AKS 代理程式節點分散到實體個別的數據中心，將 Azure 區域內的復原能力最大化。 藉由將節點集區分散到多個區域，即使另一個區域已關閉，一個節點集區中的節點仍會繼續執行。 如果共置需求存在，則可以將一般 虛擬機器擴展集 型 AKS 部署部署到單一區域或鄰近放置群組，以將節點間延遲降至最低。
叢集架構： 藉由部署在不同 Azure 區域部署的 AKS 叢集，以最大化可用性並提供商務持續性，以採用 多重區域策略 。 因特網對向工作負載應利用 Azure Front Door 或 Azure 流量管理員，跨 AKS 叢集全域路由傳送流量。
叢集和工作負載架構：在應用程式部署指令清單中定義Pod資源要求和限制，並使用 Azure 原則強制執行。 容器 CPU 和記憶體資源限制是必要的，以避免 Kubernetes 叢集中的資源耗盡。
叢集和工作負載架構： 讓系統節點集區與應用程式工作負載保持隔離。 系統節點集區需要至少 2 個 vCPU 和 4 GB 記憶體的 VM SKU，但建議使用 4 個 vCPU 或更多。 如需詳細需求，請參閱 系統與用戶節點集 區。
叢集和工作負載架構： 根據特定需求，將應用程式分成專用節點集區。 應用程式可能會共用相同的設定，而且需要已啟用 GPU 的 VM、CPU 或記憶體優化 VM，或調整為零的能力。 避免大量的節點集區，以減少額外的管理額外負荷。
叢集架構： 針對執行可進行許多並行輸出連線之工作負載的叢集使用NAT閘道。 為了避免 Azure Load Balancer 限制與高並行輸出流量的可靠性問題，我們改為 NAT 閘道 ，以支援大規模的可靠輸出流量。

如需更多建議，請參閱 可靠性要素的原則。

Azure 原則

Azure Kubernetes Service 提供各種不同的內建 Azure 原則，適用於 Azure 資源，例如典型的 Azure 原則，以及使用適用於 Kubernetes 的 Azure 原則 附加元件，也適用於叢集中。 這裡摘要說明許多與此支柱相關的重要原則。 如需更詳細的檢視，請參閱 Kubernetes 的內建原則定義。

叢集和工作負載架構

  • 叢集已針對Pod規格設定整備或活躍度健康情況 探查 。

除了內建 Azure 原則 定義之外，還可以針對 AKS 資源和 Kubernetes 的 Azure 原則 附加元件建立自定義原則。 這可讓您新增您想要在叢集和工作負載架構中強制執行的其他可靠性條件約束。

安全性

安全性是任何架構中最為重要的部分。 若要探索 AKS 如何增強應用程式工作負載的安全性，建議您檢閱 安全性設計原則。 如果您的 Azure Kubernetes Service 叢集必須設計為執行符合支付卡產業數據安全性標準（PCI-DSS 3.2.1）法規需求的敏感性工作負載，請檢閱 PCI-DSS 3.2.1 的 AKS 管制叢集。

若要瞭解使用 AKS 的 DoD 影響層級 5 （IL5） 支援和需求，請檢閱 Azure Government IL5 隔離需求。

使用 Azure Kubernetes Service 討論安全性時，請務必區分叢集安全性和工作負載安全性。 叢集安全性是叢集管理員與其資源提供者之間的共同責任，而工作負載安全性是開發人員的網域。 Azure Kubernetes Service 對這兩個角色有所考量和建議。

在 下列設計檢查清單 和建議 清單中 ，會發出圖說文字來指出每個選擇是否適用於叢集架構、工作負載架構或兩者。

設計檢查清單

  • 叢集架構： 使用 受控識別 來避免管理和輪替服務原則。
  • 叢集架構： 使用 Kubernetes 角色型訪問控制 （RBAC） 搭配 Microsoft Entra 標識符，以 取得最低許可權 存取權，並將授與系統管理員許可權降到最低，以保護設定和秘密存取。
  • 叢集架構： 使用適用於容器的 Microsoft Defender 搭配 Azure Sentinel 來偵測並快速回應叢集和工作負載上執行的威脅。
  • 叢集架構： 部署私人 AKS 叢集，以確保 API 伺服器的叢集管理流量會保留在專用網路上。 或使用非私人叢集的 API 伺服器允許清單。
  • 工作負載架構：使用 Web 應用程式防火牆 來保護 HTTP（S） 流量。
  • 工作負載架構： 請確定您的 CI/CID 管線已使用容器感知掃描強化。

建議

探索下表的建議，以優化 AKS 設定的安全性。

建議 優點
叢集架構： 使用 Microsoft Entra 整合。 使用 Microsoft Entra ID 可集中管理身分識別管理元件。 使用者帳戶或群組狀態的任何變更都會在存取 AKS 叢集時自動更新。 Kubernetes 叢集的開發人員和應用程式擁有者需要存取不同的資源。
叢集架構： 向 Azure Container Registry 驗證Microsoft項目標識符。 AKS 和 Microsoft Entra ID 可讓您使用 Azure Container Registry 進行驗證，而不需使用 imagePullSecrets 秘密。 如需詳細資訊，請參閱 從 Azure Kubernetes Service 向 Azure Container Registry 進行驗證。
叢集架構： 使用 私人 AKS 叢集保護 API 伺服器的網路流量。 根據預設，節點集區和 API 伺服器之間的網路流量會移動Microsoft骨幹網路;藉由使用私人叢集，您可以確保 API 伺服器的網路流量只會保留在專用網上。
叢集架構： 針對非私人 AKS 叢集，請使用 API 伺服器授權的 IP 範圍。 使用公用叢集時，您仍然可以使用授權的IP範圍功能來限制可觸達叢集 API 伺服器的流量。 包含來源，例如部署組建代理程式的公用IP、作業管理和節點集區的輸出點（例如 Azure 防火牆）。
叢集架構： 使用 Microsoft Entra RBAC 保護 API 伺服器。 保護 Kubernetes API Server 的存取權是保護叢集安全最重要的工作之一。 將 Kubernetes 角色型存取控制 （RBAC） 與 Microsoft Entra ID 整合，以控制 API 伺服器的存取權。 停用本機帳戶 ，以使用 Microsoft Entra ID 型身分識別強制執行所有叢集存取。
叢集架構： 使用 Azure 網路原則 或 Calico。 保護和控制叢集中 Pod 之間的網路流量。
叢集架構：使用 Azure 原則 保護叢集和 Pod。 Azure 原則 可協助您以集中式、一致的方式，大規模地在叢集上套用強制和保護。 它也可以控制授與哪些函式 Pod，以及是否有任何功能正在針對公司原則執行。
叢集架構： 保護對資源的容器存取。 限制存取容器可執行的動作。 提供最少的許可權數目，並避免使用根或特殊許可權提升。
工作負載架構：使用 Web 應用程式防火牆 來保護 HTTP（S） 流量。 若要掃描連入流量是否有潛在攻擊，請使用 Azure 應用程式閘道 或 Azure Front Door 上的 Azure Web 應用程式防火牆 （WAF） 等 Web 應用程式防火牆。
叢集架構： 控制叢集輸出流量。 請確定叢集的輸出流量會通過網路安全性點，例如 Azure 防火牆 或 HTTP Proxy。
叢集架構：使用開放原始碼 Microsoft Entra 工作負載 ID 和秘密存放區 CSI 驅動程式搭配 Azure 金鑰保存庫。 使用強式加密保護及輪替 Azure 金鑰保存庫 中的秘密、憑證和 連接字串。 提供存取稽核記錄，並將核心秘密保留在部署管線外。
叢集架構： 使用 適用於容器的 defender Microsoft。 監視和維護叢集、容器及其應用程式的安全性。

如需詳細資訊，請參閱 安全性要素的原則。

Azure Advisor 可協助確保及改善 Azure Kubernetes 服務。 它會針對下列原則區段中所列專案的子集提出建議，例如未設定 RBAC 的叢集、缺少 Microsoft Defender 設定、不受限制的網路存取 API Server。 同樣地，它會針對某些 Pod 安全性計劃專案提出工作負載建議。 檢閱 建議。

原則定義

Azure 原則 提供各種適用於 Azure 資源和 AKS 的內建原則定義，例如標準原則定義，以及在叢集中使用適用於 Kubernetes 的 Azure 原則 附加元件。 許多 Azure 資源原則都同時出現在稽核/拒絕中，但也出現在部署 If Not Exists 變體中。

這裡摘要說明許多與此支柱相關的重要原則。 如需更詳細的檢視，請參閱 Kubernetes 的內建原則定義。

叢集架構

  • 以 適用於雲端的 Microsoft Defender 為基礎的原則
  • 驗證模式和設定原則（Microsoft Entra ID、RBAC、停用本機驗證）
  • API Server 網路存取原則，包括私人叢集

叢集和工作負載架構

  • Kubernetes 叢集 Pod 安全性計劃以 Linux 為基礎的工作負載
  • 包含 Pod 和容器功能原則，例如 AppArmor、sysctl、安全性上限、SELinux、seccomp、特殊許可權容器、自動掛接叢集 API 認證
  • 掛接、磁碟區驅動程序和文件系統原則
  • Pod/容器網路原則，例如主機網路、埠、允許的外部IP、HTTP和內部負載平衡器

Azure Kubernetes Service 部署通常也會針對 Helm 圖表和容器映像使用 Azure Container Registry。 Azure Container Registry 也支援各種跨越網路限制、訪問控制和 適用於雲端的 Microsoft Defender 的 Azure 原則，其可補充安全的 AKS 架構。

除了內建原則之外，也可以針對 AKS 資源建立自定義原則，以及針對 Kubernetes 的 Azure 原則 附加元件建立自定義原則。 這可讓您新增您想要在叢集和工作負載架構中強制執行的其他安全性條件約束。

如需更多建議，請參閱 AKS 安全性概念，並根據 CIS Kubernetes 基準檢驗評估我們的安全性強化建議。

成本最佳化

成本最佳化是瞭解不同的設定選項和建議的最佳做法，以減少不必要的費用並提升作業效率。 在您遵循本文中的指引之前，建議您先檢閱下列資源：

使用 Azure Kubernetes Service 討論成本最佳化時，請務必區分叢集資源成本與工作負載資源成本。 叢集資源是叢集管理員與其資源提供者之間的共同責任，而工作負載資源則是開發人員的範圍。 Azure Kubernetes Service 對這兩個角色有所考量和建議。

在 設計檢查清單 和建議 清單中，會發出圖說文字來指出每個選擇是否適用於叢集架構、工作負載架構或兩者。

如需叢集成本優化，請移至 Azure 定價計算機 ，然後從可用的產品中選取 [Azure Kubernetes Service ]。 您可以在計算機中測試不同的組態和付款方案。

設計檢查清單

  • 叢集架構： 針對預期長期容量的每個節點集區和保留執行個體使用適當的 VM SKU。
  • 叢集和工作負載架構： 使用適當的受控磁碟階層和大小。
  • 叢集架構： 檢閱效能計量，從 CPU、記憶體、儲存體和網路開始，以依叢集、節點和命名空間找出成本最佳化機會。
  • 叢集和工作負載架構： 使用自動調整程式在工作負載較不作用時相應縮小。

建議

探索下表中的建議，為了成本調整出最佳的 AKS 設定。

建議 優點
叢集和工作負載架構： 讓 SKU 選取範圍和受控磁碟大小與工作負載需求保持一致。 比對您的選擇與您的工作負載需求，可確保您不支付不必要的資源費用。
叢集架構： 選取正確的虛擬機實例類型。 選取正確的虛擬機實例類型非常重要，因為它直接影響到AKS上執行應用程式的成本。 選擇沒有適當使用率的高效能實例可能會導致浪費費用，而選擇較不強大的實例可能會導致效能問題並增加停機時間。 若要判斷正確的虛擬機實例類型，請考慮工作負載特性、資源需求和可用性需求。
叢集架構：根據Arm架構選取虛擬機。 AKS 支援 建立 Arm64 Ubuntu 代理程序節點，以及叢集中的 Intel 和 ARM 架構節點混合，以較低的成本帶來更佳的效能。
叢集架構：選取 [Azure Spot 虛擬機器]。 現成 VM 可讓您利用未使用 Azure 容量和可觀的折扣 (相較於隨用隨付價格，折扣最高可至 90%)。 如果 Azure 需要收回容量，Azure 基礎結構會收回現成節點。
叢集架構： 選取適當的區域。 由於許多因素，資源成本會因 Azure 中的每個區域而異。 評估成本、延遲和合規性需求，以確保您以符合成本效益的方式執行工作負載，且不會影響您的終端使用者或建立額外的網路費用。
工作負載架構： 維護小型和優化的映像。 簡化映像有助於降低成本，因為新節點需要下載這些映像。 以允許容器儘快啟動的方式建置映射，以協助避免應用程式啟動時使用者要求失敗或逾時，可能會導致過度布建。
叢集架構： 啟用 叢集自動調整程式 ，以自動減少代理程序節點數目，以響應資源容量過剩。 自動相應減少 AKS 叢集中的節點數目，可讓您在需求不足時執行有效率的叢集，並在需求傳回時相應增加。
叢集架構： 啟用 節點自動布建 ，以自動選取 VM SKU。 節點自動布建可簡化 SKU 選取程式，並根據擱置的 Pod 資源需求，決定以最有效率且符合成本效益的方式執行工作負載的最佳 VM 組態。
工作負載架構： 使用 水準Pod自動調整程式。 根據 CPU 使用率或其他支援叢集相應縮小作業的選取計量，調整部署中的 Pod 數目。
工作負載架構： 使用 垂直 Pod 自動調整程式 （預覽）。 將您的 Pod 許可權化，並根據歷程記錄使用量動態設定 要求和限制 。
工作負載架構： 使用 Kubernetes 事件驅動自動調整 （KEDA）。 根據正在處理的事件數目進行調整。 從 50+ KEDA 縮放器豐富的目錄中選擇。
叢集和工作負載架構： 採用雲端財務專業領域和文化實踐，以推動雲端使用量的擁有權。 啟用成本優化的基礎是節省成本叢集的分散。 財務作業方法 （FinOps） 通常用來協助組織降低雲端成本。 這是一種做法，涉及財務、營運和工程小組之間的共同作業，以推動成本節約目標的一致性，並讓雲端成本保持透明度。
叢集架構： 註冊 Azure 保留 或 Azure 節省方案。 如果您已正確規劃容量，您的工作負載是可預測的，並存在一段較長的時間，請註冊 Azure 保留 或 節省計劃 ，以進一步降低您的資源成本。
叢集架構： 檢閱 使用 Azure 監視器 監視 Kubernetes 的最佳做法，以判斷工作負載的最佳監視策略。 N/A
叢集架構： 設定 AKS 成本分析附加元件。 成本分析叢集延伸模組可讓您深入瞭解與叢集或命名空間中各種 Kubernetes 資源相關聯的成本。

如需詳細資訊，請參閱 成本優化要素 的原則和 Azure Kubernetes Service 中的優化成本。

原則定義

雖然沒有與成本優化相關的內建原則，但可以針對AKS資源和 Kubernetes 的 Azure 原則 附加元件建立自定義原則。 這可讓您新增您想要在叢集和工作負載架構中強制執行的額外成本優化條件約束。

雲端效率

讓工作負載更具 可持續性和雲端效率，需要結合成本 優化、 減少碳排放以及 優化能耗的努力。 將應用程式的成本優化是讓工作負載更具持續性的初始步驟。

瞭解如何在 Azure Kubernetes Service （AKS） 中的可持續軟體工程原則中建置可持續且有效率的 AKS 工作負載。

卓越營運

監視和診斷非常重要。 您不僅可以測量效能統計數據，還可以快速使用計量疑難解答和補救問題。 建議您檢閱 營運卓越設計原則 和 Day-2 作業指南。

使用 Azure Kubernetes Service 討論卓越營運時，請務必區分 叢集營運卓越 和 工作負載營運卓越。 叢集作業是叢集管理員與其資源提供者之間的共同責任，而工作負載作業則是開發人員的網域。 Azure Kubernetes Service 對這兩個角色有所考量和建議。

在 下列設計檢查清單 和建議 清單中 ，會發出圖說文字來指出每個選擇是否適用於叢集架構、工作負載架構或兩者。

設計檢查清單

  • 叢集架構： 使用 Bicep、Terraform 或其他專案以範本為基礎的部署。 請確定所有部署都是可重複的、可追蹤的，並儲存在原始程式碼存放庫中。
  • 叢集架構： 建置自動化程式，以確保叢集已使用必要的全叢集組態和部署來啟動。 這通常會使用 GitOps 來執行。
  • 工作負載架構： 在您的軟體開發生命週期內，針對您的工作負載使用可重複且自動化的部署程式。
  • 叢集架構： 啟用診斷設定，以確保記錄控制平面或核心 API 伺服器互動。
  • 叢集和工作負載架構： 檢閱 使用 Azure 監視器 監視 Kubernetes 的最佳做法，以判斷工作負載的最佳監視策略。
  • 工作負載架構： 工作負載應設計為發出可收集的遙測，其中也應該包含即時線和整備狀態。
  • 叢集和工作負載架構： 使用以 Kubernetes 為目標的混亂工程實務來識別應用程式或平臺可靠性問題。
  • 工作負載架構： 將您的工作負載優化，以在容器中有效率地運作和部署。
  • 叢集和工作負載架構：使用 Azure 原則 強制執行叢集和工作負載治理。

建議

探索下表的建議，以針對作業優化 AKS 組態。

建議 優點
叢集和工作負載架構： 檢閱 AKS 最佳做法 檔。 若要在 AKS 中成功建置及執行應用程式，有重要考慮可瞭解並實作。 這些區域包括多租使用者和排程器功能、叢集和 Pod 安全性，或商務持續性和災害復原。
叢集和工作負載架構： 檢閱 Azure Chaos Studio。 Azure Chaos Studio 可協助模擬錯誤並觸發災害復原情況。
叢集和工作負載架構： 檢閱 使用 Azure 監視器 監視 Kubernetes 的最佳做法，以判斷工作負載的最佳監視策略。 N/A
叢集架構： 藉由部署在不同 Azure 區域部署的 AKS 叢集，以最大化可用性並提供商務持續性，以採用 多重區域策略 。 因特網面向的工作負載應利用 Azure Front Door 或 Azure 流量管理員，在 AKS 叢集之間全域路由傳送流量。
叢集架構：使用 Azure 原則 來運作叢集和 Pod 設定標準。 Azure 原則 可協助您以集中式、一致的方式，大規模地在叢集上套用強制和保護。 它也可以控制授與哪些函式 Pod，以及是否有任何功能正在針對公司原則執行。
工作負載架構： 在您的發行工程程式中使用平臺功能。 Kubernetes 和輸入控制器支援許多進階部署模式，以納入您的發行工程程式。 請考慮藍綠部署或 Canary 版本等模式。
叢集和工作負載架構： 對於任務關鍵性工作負載，請使用戳記層級的藍色/綠色部署。 將您的任務關鍵性設計區域自動化，包括 部署和測試。

如需更多建議，請參閱 卓越營運支柱的原則。

Azure Advisor 也會針對下列原則區段中所列專案的子集提出建議，例如不支援的 AKS 版本和未設定的診斷設定。 同樣地，它會針對使用預設命名空間提出工作負載建議。

原則定義

Azure 原則 提供各種適用於 Azure 資源和 AKS 的內建原則定義，例如標準原則定義，以及在叢集中使用適用於 Kubernetes 的 Azure 原則 附加元件。 許多 Azure 資源原則都同時出現在稽核/拒絕中，但也出現在部署 If Not Exists 變體中。

這裡摘要說明許多與此支柱相關的重要原則。 如需更詳細的檢視，請參閱 Kubernetes 的內建原則定義。

叢集架構

  • 適用於 Kubernetes 的 Azure 原則 附加元件
  • GitOps 設定原則
  • 診斷設定原則
  • AKS 版本限制
  • 防止命令叫用

叢集和工作負載架構

  • Namespace部署限制

除了內建原則之外，還可以針對 AKS 資源和 Kubernetes 的 Azure 原則 附加元件建立自定義原則。 這可讓您新增您想要在叢集和工作負載架構中強制執行的其他安全性條件約束。

效能效益

效能效率可讓您的工作負載進行調整，以有效率的方式符合使用者對其放置的需求。 建議您檢閱 效能效率原則。

使用 Azure Kubernetes Service 討論效能時，請務必區分 叢集效能 和 工作負載效能。 叢集效能是叢集管理員與其資源提供者之間的共同責任，而工作負載效能是開發人員的網域。 Azure Kubernetes Service 對這兩個角色有所考量和建議。

在 下列設計檢查清單 和建議 清單中 ，會發出圖說文字來指出每個選擇是否適用於叢集架構、工作負載架構或兩者。

設計檢查清單

當您為 Azure Kubernetes Service 進行設計選擇時，請檢閱 效能效率原則。

  • 叢集和工作負載架構： 執行並反覆運算包含 SKU、自動調整設定、IP 尋址和故障轉移考慮的詳細容量計劃練習。
  • 叢集架構： 啟用 叢集自動調整程式 ，以自動調整回應工作負載需求中的代理程序節點數目。
  • 叢集架構： 使用 水準Pod自動調整程式 ，根據CPU使用率或其他選取計量來調整部署中的Pod數目。
  • 叢集和工作負載架構： 執行可同時執行 Pod 和叢集自動調整程式的持續負載測試活動。
  • 叢集和工作負載架構： 將工作負載分成不同的節點集區，以允許獨立調整。

建議

探索下列建議表格，以將 Azure Kubernetes Service 組態優化以達到效能。

建議 優點
叢集和工作負載架構： 開發詳細的容量計劃，並持續檢閱和修訂。 正式化容量計劃之後，應該透過持續觀察叢集的資源使用率來經常更新。
叢集架構： 啟用 叢集自動調整程式 ，以自動調整代理程序節點數目，以響應資源限制。 自動相應增加或減少 AKS 叢集中節點數目的能力可讓您執行有效率且符合成本效益的叢集。
叢集和工作負載架構： 將工作負載分成不同的節點集區，並考慮 調整 用戶節點集區。 不同於一律需要執行中節點的系統節點集區，用戶節點集區可讓您相應增加或減少。
工作負載架構： 使用 AKS 進階排程器功能。 協助控制需要資源的工作負載平衡。
工作負載架構： 使用有意義的工作負載調整計量。 並非所有規模決策都可以衍生自 CPU 或記憶體計量。 規模考慮通常來自更複雜的甚至外部數據點。 使用 KEDA 根據工作負載專屬的訊號來建置有意義的自動調整規則集。

如需更多建議，請參閱 效能效率要素的原則。

原則定義

Azure 原則 提供各種適用於 Azure 資源和 AKS 的內建原則定義，例如標準原則定義，以及在叢集中使用適用於 Kubernetes 的 Azure 原則 附加元件。 許多 Azure 資源原則都同時出現在稽核/拒絕中，但也出現在部署 If Not Exists 變體中。

這裡摘要說明許多與此支柱相關的重要原則。 如需更詳細的檢視，請參閱 Kubernetes 的內建原則定義。

叢集和工作負載架構

  • CPU 和記憶體資源限制

除了內建原則之外，也可以為 AKS 資源建立自定義原則，以及針對 Kubernetes 的 Azure 原則 附加元件建立自定義原則。 這可讓您新增您想要在叢集和工作負載架構中強制執行的其他安全性條件約束。

其他資源

Azure 架構中心指引

雲端採用架構 指引

下一步