Azure Well-Architected Framework 檢閱 - Azure Kubernetes Service (AKS)

  • 發行項

本文提供 Azure Kubernetes Service (AKS) 的架構最佳做法。 指導方針是以架構卓越五大要素為基礎：

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

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

必要條件

瞭解 Well-Architected 架構要素有助於產生高品質、穩定且有效率的雲端架構。 建議您使用 Azure Well-Architected Framework 檢閱 評估來檢閱您的工作負載。

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

可靠性

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

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

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

設計檢查清單

  • 叢集架構： 針對重要工作負載，請使用 AKS 叢集 的可用性區域 。
  • 叢集架構： 規劃IP位址空間，以確保叢集可以可靠地調整，包括處理多叢集拓撲中的故障轉移流量。
  • 叢集架構： 啟用 容器深入解析 來監視您的叢集，並設定可靠性影響事件的警示。
  • 工作負載架構： 確定已建置工作負載，以支援水平調整和報告應用程式整備程度和健康情況。
  • 叢集和工作負載架構： 請確定您的工作負載正在用戶節點集區上執行，然後選擇正確的大小 SKU。 至少包含使用者節點集區的兩個節點，以及系統節點集區的三個節點。
  • 叢集架構： 使用 AKS 執行時間 SLA 來符合生產工作負載的可用性目標。

AKS 設定建議

探索下表的建議，以優化您的 AKS 組態以進行可靠性。

建議 優點
叢集和工作負載架構： 使用節點選取器和親和性來控制Pod排程。 讓 Kubernetes 排程器以邏輯方式依節點中的硬體隔離工作負載。 不同於 交錯，沒有相符節點選取器的 Pod 可以排程在已標記的節點上，這可讓節點上未使用的資源取用，但優先於定義相符節點選取器的 Pod。 使用節點親和性以獲得更大的彈性，其可讓您定義當 Pod 無法與節點相符時要發生的情況。
叢集架構： 請根據網路需求和叢集大小，確定適當地選取網路外掛程式。 特定情況會需要 Azure CNI，例如 Windows 型節點集區、特定網路需求，以及 Kubernetes 網路原則。 如需詳細資訊 ，請參閱 Kubenet 與 Azure CNI 。
叢集和工作負載架構： 針對生產等級叢集使用 AKS 運行時間 SLA 。 AKS 運作時間 SLA 保證：
- 使用 Azure 可用性區域的 AKS 叢集的 Kubernetes API 伺服器端點的 99.95% 可用性，或
- 未使用 Azure 可用性區域的 AKS 叢集的 99.9% 可用性。
叢集和工作負載架構： 使用 容器深入解析設定叢集的監視。 容器深入解析可透過計量 API 監視 Kubernetes 中可用的控制器、節點和容器的健康情況和效能。 與 Prometheus 整合可收集應用程式和工作負載計量。
叢集架構： 使用 可用性區域 ，將 AKS 代理程式節點分散到實體個別數據中心，將 Azure 區域內的復原能力最大化。 藉由將節點集區分散到多個區域，即使另一個區域已關閉，一個節點集區中的節點仍會繼續執行。 如果共置需求存在，則可以將一般 VMSS 型 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 的內建原則定義。

叢集和工作負載架構

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

安全性

安全性是任何架構中最重要的其中一個層面。 若要探索 AKS 如何強化應用程式工作負載的安全性，建議您檢閱 安全性設計原則。 如果您的 Azure Kubernetes Service 叢集必須設計為執行符合付款卡產業數據安全性標準 (PCI-DSS 3.2.1) 的敏感性工作負載，請檢閱 PCI-DSS 3.2.1 的 AKS 管制叢集。

若要瞭解 DoD 影響等級 5 (IL5) AKS 的支援和需求，請檢閱 Azure Government IL5 隔離需求。

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

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

設計檢查清單

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

建議

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

建議 優點
叢集架構：使用 Microsoft Entra整合。 使用 Microsoft Entra ID 集中身分識別管理元件。 在存取 AKS 叢集時，使用者帳戶或群組狀態中的任何變更都將自動更新。 Kubernetes 叢集的開發人員和應用程式擁有者需要存取不同的資源。
叢集架構：使用 Microsoft Entra ID 進行驗證以 Azure Container Registry。 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 伺服器的存取，是確保叢集安全可以執行的其中一項重要工作。 將 Kubernetes 角色型存取控制 (RBAC) 與 Microsoft Entra ID整合，以控制 API 伺服器的存取。 停用本機帳戶，以使用以 Microsoft Entra ID 為基礎的身分識別強制執行所有叢集存取。
叢集架構： 使用 Azure 網路原則 或 Calico。 保護和控制叢集中 Pod 之間的網路流量。
叢集架構：使用 Azure 原則 保護叢集和 Pod。 Azure 原則 可協助以集中式、一致的方式在叢集上套用大規模強制執行和保護。 也可以控制要授與的函式 Pod，以及是否有任何針對公司原則執行的功能。
叢集架構： 保護對資源的容器存取。 限制存取容器可執行的動作。 提供最低權限，並且避免使用根或權限提升。
工作負載架構：使用 Web 應用程式防火牆 來保護 HTTP (S) 流量。 若要掃描連入流量是否有潛在攻擊，請使用 Web 應用程式防火牆，例如 Azure Web 應用程式防火牆 (WAF) Azure 應用程式閘道 或 Azure Front Door。
叢集架構： 控制叢集輸出流量。 請確定叢集的輸出流量會通過網路安全性點，例如 Azure 防火牆 或 HTTP Proxy。
叢集架構：搭配 Azure 金鑰保存庫 使用開放原始碼 Microsoft Entra 工作負載 ID 和秘密存放區 CSI 驅動程式。 使用強式加密保護及輪替 Azure 金鑰保存庫 中的秘密、憑證和連接字串。 提供存取稽核記錄，並將核心秘密保留在部署管線外。
叢集架構：針對容器使用 Microsoft Defender。 監視和維護叢集、容器及其應用程式的安全性。

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

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

原則定義

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

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

叢集架構

  • 雲端式原則的 Microsoft Defender
  • 驗證模式和設定原則 (Microsoft Entra ID、RBAC、停用本機驗證)
  • API 伺服器網路存取原則，包括私人叢集

叢集和工作負載架構

  • 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 保留 或 節省方案 ，以進一步降低您的資源成本。
叢集架構： 使用 容器深入解析設定叢集的監視。 容器深入解析可協助提供叢集閑置和未配置資源的可採取動作深入解析。 容器深入解析也支援收集 Prometheus 計量，並與 Azure 受控 Grafana 整合，以全面檢視您的應用程式和基礎結構。
叢集架構： 設定 AKS 成本分析附加元件。 成本分析叢集延伸模組可讓您深入瞭解與叢集或命名空間中各種 Kubernetes 資源相關聯的成本。

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

原則定義

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

雲端效率

讓工作負載更具 持續性和雲端效率，需要結合 成本優化、 降低碳量，以及 優化能源耗用量。 優化應用程式的成本是讓工作負載更具持續性的初始步驟。

瞭解如何在 Azure Kubernetes Service (AKS) 的永續性軟體工程原則中，建置永續且有效率的 AKS 工作負載。

卓越營運

監視和診斷能力極為重要。 您不僅能測量效能統計數據，還能快速使用計量疑難解答和補救問題。 我們建議您檢閱 營運卓越設計原則 和 第 2 天作業指南。

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

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

設計檢查清單

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

建議

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

建議 優點
叢集和工作負載架構： 檢閱 AKS 最佳做法 檔。 若要在 AKS 中成功建置和執行應用程式，請務必瞭解並實作重要考慮。 這些區域包含多租用戶與排程器功能、叢集與 Pod 安全性，或商務持續性和災害復原。
叢集和工作負載架構： 檢閱 Azure Chaos Studio。 Azure Chaos Studio 可協助模擬錯誤並觸發災害復原情況。
叢集和工作負載架構： 使用 容器深入解析設定叢集的監視。 容器深入解析可透過計量 API 和容器記錄，從 Kubernetes 中可用的控制器、節點和容器收集記憶體和處理器計量，藉此協助監視容器的效能。
工作負載架構： 使用 Azure 監視器監視應用程式效能。 設定 Application Insights 以程式代碼為基礎的監視 AKS 叢集中執行的應用程式。
工作負載架構： 使用容器深入解析設定擷取 Prometheus 計量。 容器深入解析是 Azure 監視器的一部分，可提供順暢的上線體驗來收集 Prometheus 計量。 如需詳細資訊 ，請參閱設定擷取 Prometheus 計量 。
叢集架構： 藉由部署跨不同 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 版本限制
  • 防止命令叫用

叢集和工作負載架構

  • 命名空間部署限制

除了內建原則之外，還可以針對 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 架構中心指引

雲端採用架構指引

下一步