共用方式為

Azure Well-Architected 框架視角 Azure Kubernetes Service （AKS）

  • 發行項

Azure Kubernetes Service （AKS） 是受控 Kubernetes 服務，可用來部署和管理容器化應用程式。 與其他受控服務類似，AKS 會將大部分作業額外負荷卸除至 Azure，同時為工作負載提供高可用性、延展性和可移植性功能。

本文假設您身為架構設計師，已檢閱 運算決策樹，並選擇 AKS 作為工作負載的運算平台。 本文中的指引提供架構建議，這些建議會映射到 Azure 架構框架的 原則 Well-Architected支柱。

重要

如何使用本指南

每個區段都有一個 設計檢查清單，呈現架構重點關注區域及針對技術範圍調整的設計策略。

此外，也包含可協助具體化這些策略的技術功能建議。 建議並不代表 AKS 及其相依性可用之所有組態的完整清單。 相反地，他們列出對應至設計觀點的關鍵建議。 使用建議來建置概念證明，或將現有的環境優化。

示範主要建議的基礎架構：AKS 基準架構。

技術範圍

此檢閱著重於下列 Azure 資源的相關決策：

  • AKS

當您討論 AKS 的 Well-Architected 架構要素最佳做法時，請務必區分 叢集 和 工作負載。 叢集最佳做法是叢集管理員與其資源提供者之間的共同責任，而工作負載最佳做法是開發人員的網域。 本文針對每個角色都有考慮和建議。

注意

下列要素包括 設計檢查清單，以及 建議清單，指出每個選擇都適用於 叢集 架構、工作負載 架構，或兩者皆適用。

可靠性

可靠性支柱的目的是藉由 建置足夠的復原能力，以及從失敗快速復原的能力，來提供持續的功能。

可靠性設計原則 提供適用於個別元件、系統流程和整個系統的高階設計策略。

設計檢查清單

請根據可靠性 的設計檢閱檢查清單，開始您的設計策略。 在記住 AKS 的功能及其相依性的同時，判斷其與業務需求的相關性。 擴充策略，以視需要包含更多方法。

  • （叢集） 建立備援以改善復原能力。 將 AKS 叢集的可用性區域作為復原策略的一部分，以在部署至單一區域時增加可用性。 許多 Azure 區域都提供可用性區域。 這些區域足夠接近，可以實現低延遲的連線，但也有適當的距離，以降低局部故障影響多個區的可能性。

    對於重要的工作負載，請跨不同的 Azure 區域部署多個叢集。 透過分散 AKS 叢集的地理位置，您可以達到更高的復原能力，並將區域失敗的影響降到最低。 多區域策略可協助最大化可用性並提供商務持續性。 面向網際網路的工作負載應使用 Azure Front Door 或 Azure 流量管理員，以跨 AKS 叢集全域路由流量。 如需詳細資訊，請參閱 多重區域策略。

    規劃IP位址空間，以確保叢集能夠可靠地調整及處理多個叢集拓撲中的故障轉移流量。

  • （叢集和工作負載）監視叢集和工作負載的可靠性與整體健康情況指標。 收集記錄和計量來監視工作負載健康情況、識別效能和可靠性趨勢，以及針對問題進行疑難解答。 請檢閱 使用 Azure 監視器 監視 Kubernetes 的最佳做法，以及工作負載的 Well-Architected 健康情況模型化 指南，以協助設計 AKS 解決方案的可靠性與健康情況監視解決方案。

    確保工作負載已建構以支援水平調整，並能報告應用程式的準備狀態和健康狀況。

  • （叢集和工作負載）主機應用程式 Pod 於使用者節點集區中。 藉由隔離系統 Pod 與應用程式工作負載，有助於確保 AKS 基本服務不受執行使用者節點集區之工作負載所造成的資源需求或潛在問題影響。

    請確定您的工作負載會在用戶節點集區上執行，並選擇正確的 SKU 大小。 至少包含使用者節點集區的兩個節點，以及系統節點集區的三個節點。

  • （叢集和工作負載）將 AKS 執行時間服務等級協定（SLA）納入您的可用性和復原目標。 若要定義叢集和工作負載的可靠性與復原目標，請遵循 建議中的指引來定義可靠性目標。 然後制定符合這些目標的設計。

  • （叢集和工作負載）使用 Azure 備份來保護 AKS 叢集服務，方法是將恢復點儲存在備份保存庫中，並在任何災害案例期間執行還原。 若要備份和還原在 AKS 叢集中執行的容器化應用程式和數據，請遵循 AKS 備份概觀中的指引來設定保護。

建議

建議 優點
（叢集和工作負載）使用節點選取器和親和性來控制Pod排程。

在 AKS 中，Kubernetes 排程器可以透過節點中的硬體，以邏輯方式隔離工作負載。 與 容忍性不同，沒有相符的節點選取器的 Pod 也可以排程至已標記的節點，但會優先排程至符合節點選取器的 Pod。		 節點親和性提供更大的彈性，使您能夠定義當 Pod 無法與節點匹配時會發生什麼情況。
（叢集）根據網路需求和叢集大小選擇適當的網路外掛程式。

不同的網路外掛程式提供不同層級的功能。 特定案例需要 Azure 容器網路介面 （Azure CNI），例如 Windows 節點集區、某些網路需求，以及 Kubernetes 網路原則。

如需詳細資訊，請參閱 Kubenet 與 Azure CNI。		 正確的網路外掛程式有助於確保更好的相容性和效能。
（叢集和工作負載）使用 AKS 正常運行時間 SLA 用於生產等級叢集。 工作負載可以支援更高的可用性目標，因為 AKS 叢集的 Kubernetes API 伺服器端點可用性保證較高。
（叢集）使用 可用性區域，藉由將 AKS 代理程式節點分散到實體個別的數據中心，將 Azure 區域內的復原能力最大化。

如果有共置需求，請使用基於標準虛擬機擴展集的 AKS 部署到單一區域，或者使用 鄰近放置群組 以將節點間延遲降到最低。		 藉由將節點集區分散到多個區域，即使另一個區域關閉，一個節點集區中的節點仍會繼續執行。
（叢集和工作負載）在應用程式部署設定檔中定義 Pod 資源的要求和限制。 使用 Azure 原則強制執行這些限制。 容器 CPU 和記憶體資源限制是必要的，以避免 Kubernetes 叢集中的資源耗盡。
（叢集和工作負載）讓系統節點集區與應用程式工作負載保持隔離。

系統節點集區需要至少 2 個 vCPU 和 4 GB 記憶體的虛擬機器 （VM） SKU。 建議您使用 4 個 vCPU 或更多。 如需詳細資訊，請參閱 系統和用戶節點集區。		 系統節點集區負責承載對叢集控制平面而言至關重要的系統 Pod。 藉由將這些系統 Pod 與應用程式工作負載隔離，您可以協助確保基本服務不受工作負載所造成的資源需求或潛在問題影響。
（叢集和工作負載）根據特定需求，將應用程式分成專用節點集區。 避免大量的節點集區，以減少管理額外負荷。 應用程式可以共用相同的配置，並需要支援 GPU 的 VM、經過 CPU 或記憶體優化的 VM，或具備縮減至零的能力。 藉由將節點集區奉獻給特定應用程式，您可以協助確保每個應用程式都能取得所需的資源，而不需要過度布建或使用量過低的資源。
（叢集）針對執行許多並行輸出連線之工作負載的叢集，請使用 NAT 閘道。 Azure NAT 閘道支持大規模的可靠輸出流量，並藉由將 Azure Load Balancer 限制套用至高並行輸出流量，協助您避免可靠性問題。
（叢集和工作負載）使用 Azure 備份 保護 AKS 叢集，並將 還原至災害期間的替代區域。 Azure 備份支援針對叢集狀態和應用程式數據執行的容器化應用程式和數據的備份和還原作業。

您可以在區域災害案例中使用備份，並將備份復原。		 Azure 備份與 Azure Kubernetes Service （AKS） 提供完全受控、可調整、安全且符合成本效益的解決方案。 不需要設定和維護備份基礎結構的複雜性，即可增強工作負載的可靠性。

安全性

安全性要素的目的是為工作負載提供 機密性、完整性和可用性 保證。

安全性設計原則 藉由將方法套用至 AKS 的技術設計，為達成這些目標提供高階的設計策略。

設計檢查清單

根據 設計檢閱檢查清單為基礎啟動您的安全性 設計策略，並識別弱點和控件，以改善安全防護態勢。 熟悉 AKS 安全概念， 並根據 CIS Kubernetes 基準評估安全強化建議。 擴充策略，以視需要包含更多方法。

  • （叢集） 與 Microsoft Entra ID 整合，以取得 身分識別和存取管理。 使用 Microsoft Entra ID 集中管理叢集的身分識別。 使用者帳戶或群組狀態的任何變更都會在存取 AKS 叢集時自動更新。 將身分識別建立為主要安全邊界。 Kubernetes 叢集的開發人員和應用程式擁有者需要存取不同的資源。

    使用 Kubernetes 角色型存取控制 （RBAC） 搭配 Microsoft Entra 識別碼，最低許可權存取。 藉由將系統管理員許可權的配置降到最低，以保護設定和秘密。

  • （叢集） 與安全性監視和安全性資訊和事件管理工具整合。 使用適用於容器的 Microsoft Defender 搭配 Microsoft Sentinel，以偵測並快速回應叢集及其上執行之工作負載的威脅。 啟用 AKS 連接器以將您的 AKS 診斷記錄串流至 Microsoft Sentinel。

  • （叢集和工作負載）實作分割和網路控制。 若要防止數據外流，請確定只允許授權且安全的流量，並包含安全性缺口的爆破半徑。

    請考慮使用私人 AKS 叢集，協助確保 API 伺服器的叢集管理流量會保留在專用網路上。 或使用公用叢集的 API 伺服器允許清單。

  • （工作負載） 使用 Web 應用程式防火牆 （WAF） 掃描連入流量是否有潛在攻擊。 WAF 可以即時偵測並減輕威脅，以協助封鎖惡意流量，再到達您的應用程式。 它提供強大的保護，以防止常見的 Web 型攻擊，例如 SQL 插入式攻擊、跨網站腳本，以及其他開放式 Web 應用程式安全性專案弱點。 某些負載平衡器，例如 Azure 應用程式閘道 或 Azure Front Door 具有整合式 WAF。

  • （工作負載） 維護強化工作負載的軟體供應鏈。 確定您的持續整合和持續傳遞管線已使用容器感知掃描強化。

  • （叢集和工作負載）為特製化安全工作負載實作額外的保護。 如果您的叢集需要執行敏感性工作負載，您可能需要部署私人叢集。 以下是一些範例：

建議

建議 優點
（叢集）在叢集上使用 受控身分識別。 您可以避免與管理和輪替服務原則相關聯的額外負荷。
（工作負載）搭配 AKS 使用 Microsoft Entra 工作負載標識符，從您的工作負載存取 Microsoft Entra 受保護的資源，例如 Azure Key Vault 和 Microsoft Graph。 使用 AKS 工作負載標識符來保護對 Azure 資源的存取，方法是使用 Microsoft Entra ID RBAC，而不需要直接在程式代碼中管理認證。
（叢集）使用 Microsoft Entra 識別符，從 AKS 向 Azure Container Registry 進行驗證。 藉由使用 Microsoft Entra 識別符，AKS 可以使用 Container Registry 進行驗證，而不需使用 imagePullSecrets 秘密。
（叢集）如果工作負載需求需要較高層級的分割，請使用 私人 AKS 叢集來保護對 API 伺服器的網路流量。 根據預設，節點集區和 API 伺服器之間的網路流量會移動Microsoft骨幹網路。 藉由使用私人叢集，您可以協助確保 API 伺服器的網路流量只保留在專用網上。
（叢集）針對公用 AKS 叢集，請使用 API 伺服器授權的 IP 位址範圍。 包含來源，例如部署組建代理程式的公用IP位址、作業管理和節點集區的輸出點，例如 Azure 防火牆。 當您使用公用叢集時，可以藉由限制可到達叢集 API 伺服器的流量，大幅減少 AKS 叢集的攻擊面。
（叢集）使用 Microsoft Entra ID RBAC 來保護 API 伺服器。

停用本機帳戶，以使用 Microsoft Entra 識別符型身分識別強制執行所有叢集存取。		 保護 Kubernetes API 伺服器的存取權是保護叢集安全最重要的事項之一。 整合 Kubernetes RBAC 與 Microsoft Entra ID，以控制對 API 伺服器的存取。
（叢集）使用 Azure 網路原則 或 Calico。 藉由使用原則，您可以保護和控制叢集中 Pod 之間的網路流量。 Calico 提供一組更豐富的功能，包括原則排序和優先順序、拒絕規則，以及更有彈性的比對規則。
（叢集）使用 Azure 原則來保護叢集和 Pod。 Azure 原則可協助您以集中式、一致的方式，大規模地在叢集上套用強制和保護。 它還可以控制授予Pod的功能，並檢測是否有任何運行違反公司政策的內容。
（叢集）保護對資源的容器存取。 限制存取容器可執行的動作。 提供最少的許可權數目，並避免使用根或特殊許可權提升。

針對以Linux為基礎的容器，請參閱使用內建Linux安全性功能 安全性容器存取資源。		 藉由限制權限並避免使用 root 或提升特權操作，有助於降低安全漏洞的風險。 您可以協助確保即使容器遭到入侵，潛在損害也會最小化。
（叢集）藉由確保叢集的輸出流量通過網路安全性點，例如 Azure 防火牆 或 HTTP Proxy，來控制叢集輸出流量。 透過 Azure 防火牆或 HTTP Proxy 路由傳送輸出流量，您可以協助強制執行安全策略，以防止未經授權的存取和數據外流。 此方法也會簡化安全策略的管理，並讓您更輕鬆地在整個 AKS 叢集中強制執行一致的規則。
（叢集）使用開放原始碼 Microsoft Entra 工作負載標識碼，並使用 Key Vault 秘密存放區 CSI 驅動程式。 這些功能可協助您使用強式加密來保護和輪替 Key Vault 中的秘密、憑證和連接字串。 它們提供存取稽核記錄，並將核心秘密保留在部署管線外。
（叢集）使用適用於容器的 Defender Microsoft。 Microsoft適用於容器的 Defender 可協助您監視和維護叢集、容器及其應用程式的安全性。

成本優化

成本優化著重於 偵測支出模式、將投資放在重要領域，並將其他 優化，以符合組織的預算，同時符合商務需求。

成本優化設計原則 提供高階設計策略，以達成這些目標，並在與 AKS 及其環境相關的技術設計中在必要時進行取捨。

設計檢查清單

根據投資成本優化 設計檢閱檢查清單，開始您的設計策略。 微調設計，讓工作負載符合為工作負載配置的預算。 您的設計應該使用正確的 Azure 功能、監視投資，以及尋找經過一段時間優化的機會。

  • （叢集）在您的成本模型中包含 AKS 的 定價層。 若要預估成本，請使用 Azure 定價計算機，並在計算機中測試不同的組態和付款方案。

  • （叢集） 取得工作負載的最佳費率。 針對每個節點集區使用適當的 VM SKU，因為它直接影響執行工作負載的成本。 選擇沒有適當使用率的高效能 VM 可能會導致浪費費用。 選取較不強大的 VM 可能會導致效能問題，並增加停機時間。

    如果您已正確規劃容量，且工作負載可預測，且將存在一段較長的時間，請註冊 Azure Reservations 或 節省方案，以降低您的資源成本。

    選擇 Azure Spot 虛擬機，以大幅折扣使用未使用量的 Azure 容量。 這些折扣最多可達到90% 隨用隨付價格。 如果 Azure 需要收回容量，Azure 基礎結構會收回現成節點。

    如果您在內部部署或邊緣執行 AKS，也可以使用 Azure Hybrid Benefit，以在這些案例中執行容器化應用程式時降低成本。

  • （叢集和工作負載）優化工作負載元件成本。 為您的工作負載選擇最符合成本效益的區域。 評估成本、延遲和合規性需求，以確保您以符合成本效益的方式執行工作負載，且不會影響您的客戶或建立額外的網路費用。 您在 Azure 中部署工作負載的區域可能會大幅影響成本。 由於許多因素，資源成本會因 Azure 中的每個區域而有所不同。

    維護小型和優化的映像，以協助降低成本，因為新節點需要下載這些映像。 啟動應用程式時，使用者要求失敗或逾時可能會導致資源過度配置。 以允許容器儘快啟動的方式建置映射，以協助避免失敗和逾時。

    請檢閱 使用 Azure 監視器 監視 Kubernetes 的最佳做法中的成本優化建議，以判斷工作負載的最佳監視策略。 分析效能計量，從CPU、記憶體、記憶體、記憶體和網路開始，以依叢集、節點和命名空間識別成本優化機會。

  • （叢集和工作負載）優化工作負載調整成本。 考慮替代的垂直和水平調整組態，以減少調整成本，同時仍符合所有工作負載需求。 當工作負載較不活躍時，請使用自動調整程式來縮小規模。

  • （叢集和工作負載）收集和分析成本數據。 啟用成本優化的基礎是節省成本的叢集。 開發成本效益思維，包括財務、營運和工程小組之間的共同作業，以推動成本節約目標的一致性，並讓雲端成本保持透明度。

建議

建議 優點
（叢集和工作負載）將 AKS SKU 選項 及管理磁碟大小與工作負載需求對齊。 將您的選擇與工作負載需求相匹配，有助於確保您不會為不需要的資源付費。
（叢集）為 AKS 節點集區選擇正確的 VM 實例類型，。

若要判斷正確的 VM 實例類型，請考慮工作負載特性、資源需求和可用性需求。		 選取正確的 VM 實例類型非常重要，因為它直接影響到 AKS 上執行應用程式的成本。 選擇高效能實例卻沒有充分利用，可能會導致資源浪費。 選擇功能較弱的實例可能會導致效能問題並增加停機時間。
（叢集）根據更有效率的 Azure Resource Manager 架構選擇 VM。 AKS 支援 建立 Arm64 節點集區，以及叢集中 Intel 和 Resource Manager 架構節點的混合。 Arm64 架構提供較佳的價格與效能比率，因為它的功率使用率較低，且計算效能有效率。 這些功能可以降低成本來提升效能。
（叢集）啟用 叢集自動調整程式，以自動減少代理程序節點數目，以響應資源容量過剩。 自動相應減少 AKS 叢集中的節點數目，可讓您在需求較低時執行有效率的叢集，並在需求增加時相應增加。
（叢集）啟用 節點自動配置，以自動選取 VM SKU。 節點自動布建可簡化 SKU 選取程式，並根據擱置的 Pod 資源需求，決定以最有效率且符合成本效益的方式執行工作負載的最佳 VM 組態。
（工作負載）使用 HorizontalPodAutoscaler，根據 CPU 使用率或其他計量來調整部署中的 Pod 數目。 當需求較低時，自動調整以減少 Pod 的數量，當需求增加時則進行擴展，從而使工作負載的運行更具成本效益。
(工作負載) 使用 VerticalPodAutoscaler (預覽)，根據歷史使用情況，動態 設定 Pod 的需求和限制。 藉由為每個工作負載設定容器的資源要求和限制，VerticalPodAutoscaler 可釋出其他 Pod 的 CPU 和記憶體，並協助確保 AKS 叢集的有效使用率。
（叢集）設定 AKS 成本分析外掛。 成本分析叢集延伸模組可讓您深入瞭解與叢集或命名空間中各種 Kubernetes 資源相關聯的成本。

卓越營運

運營卓越主要著重於 開發實務、可觀察性和發行管理的程序。

營運卓越設計原則 提供高階設計策略，以達成工作負載作業需求的目標。

設計檢查清單

以營運卓越 的 設計檢查清單作為您的設計策略起點，定義可觀察性、測試和部署的過程。 請參閱 AKS 最佳做法 和 第 2 天操作指南 以瞭解和實作的重要考慮事項。

  • （叢集）實作基礎設施即程式碼（IaC）部署方法。 使用 Bicep、Terraform 或類似工具的宣告式、範本式的部署方法。 請確定所有部署都是可重複的、可追蹤的，並儲存在原始程式碼存放庫中。 如需詳細資訊，請參閱 AKS 產品檔中的 快速入門。

  • （叢集和工作負載）自動化基礎結構和工作負載部署。 使用標準軟體解決方案來管理、整合及自動化叢集和工作負載的部署。 整合部署管線與原始檔控制系統，並納入自動化測試。

    建置自動化程式，以協助確保您的叢集已使用必要的全叢集組態和部署來啟動。 此程式通常是使用 GitOps 來執行。

    在您的軟體開發生命週期內，針對您的工作負載使用可重複且自動化的部署程式。

  • （叢集和工作負載）實施全面的監視策略。 收集記錄和計量以監視工作負載的健康情況、找出效能和可靠性的趨勢，以及針對問題進行疑難解答。 檢閱使用 Azure 監視器 監視 Kubernetes 的 最佳做法，以及設計及建立監視系統 的 Well-Architected 建議，以判斷工作負載的最佳監視策略。

    啟用診斷設定，以確保記錄控制平面或核心 API 伺服器互動。

    工作負載應設計為發出可收集的遙測資料，這應包括存活狀態和準備狀態。

  • （叢集和工作負載）在生產策略中實作測試。 生產環境中的測試會使用實際部署來驗證及測量應用程式在生產環境中的行為和效能。 使用以 Kubernetes 為目標的混亂工程做法來識別應用程式或平臺可靠性問題。

    Azure Chaos Studio 可協助模擬錯誤並觸發災害復原情況。

  • （叢集和工作負載）強制執行工作負載控管。 Azure 原則可協助確保符合組織標準、自動化原則強制執行，並提供叢集資源的集中可見度和控制。

    請檢閱 Azure 原則 一節，以深入瞭解 AKS 可用的內建原則。

  • （叢集和工作負載）針對任務關鍵性工作負載使用 戳記層級、藍綠部署。 戳記層級、藍綠部署方法可以增加發行變更的信心，並啟用零停機升級，因為可以驗證與 Azure 平臺、資源提供者和 IaC 模組等下游相依性的相容性。

    Kubernetes 和輸入控制器支援許多進階部署模式，以納入您的發行工程程式。 請考慮藍綠部署或 Canary 版本等模式。

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

    請參閱 AKS 中的 永續性軟體工程原則，以瞭解如何建置可持續且有效率的 AKS 工作負載。

建議

建議 優點
（叢集）使用適用於 AKS 的 Azure 原則來實現叢集和 Pod 設定標準。 適用於 AKS 的 Azure 原則可協助您以集中式、一致的方式，大規模地在叢集上套用強制和保護。 使用政策來定義授予 Pod 的權限，並確保符合公司政策。
（工作負載）使用 Kubernetes 事件驅動自動調整程式 （KEDA）。 KEDA 可讓您的應用程式根據事件進行調整，例如所處理的事件數目。 您可以從 50 個以上的 KEDA 縮放器豐富的目錄中進行選擇。

效能效率

效能效率是關於 在負載增加時仍能藉由管理容量來維持用戶體驗。 此策略包括調整資源、識別和優化潛在的瓶頸，以及優化尖峰效能。

效能效率設計原則 提供針對預期使用量達成這些容量目標的高階設計策略。

設計檢查清單

根據設計檢閱檢查清單，開始您的設計策略，以效能效率為基礎，並基於AKS的關鍵效能指標來定義基準。

  • （叢集和工作負載）進行容量規劃。 執行並重複進行包含 SKU、自動調整設定、IP 位址設定和容錯切換考量的詳細容量計劃。

    正式化容量計劃之後，請持續觀察叢集的資源使用率，以經常更新計劃。

  • （叢集）定義調整策略。 設定調整，以確保資源能有效率地調整，以滿足工作負載需求，而不會過度使用或浪費。 使用 AKS 功能，例如叢集自動調整和水平 Pod 自動調整器，以動態符合您的工作負載需求，同時減輕營運的負擔。 將您的工作負載優化，以在容器中有效率地運作和部署。

    請檢閱 調整和分割 指南，以瞭解調整組態的各個層面。

  • （叢集和工作負載）進行效能測試。 執行持續負載測試活動，以練習Pod和叢集自動調整程式。 比較結果與效能目標與已建立的基準。

  • （叢集和工作負載）獨立調整工作負載和流程。 分開將工作負載和流程放入不同的節點集區，以允許獨立調整。 請遵循 中的指引，使用流程優化工作負載設計，以識別並確定流程的優先順序。

建議

建議 優點
（叢集）啟用 叢集自動調整程式，以自動調整代理程序節點數目，以回應工作負載需求。

使用 HorizontalPodAutoscaler，根據 CPU 使用率或其他計量來調整部署中的 Pod 數目。		 能夠自動擴展或縮減 AKS 叢集中的節點和 Pod 的數量的能力，可讓您運行一個有效且具有成本效益的叢集。
（叢集和工作負載）將工作負載分成不同的節點集區，並考慮調整用戶節點集區 ，以便進行擴展。 不同於系統節點集區始終需要執行節點，用戶節點集區可以進行擴展或縮減。
（工作負載）使用 AKS 進階排程器功能 針對需要資源的工作負載實作進階平衡。 當您管理 AKS 叢集時，通常需要隔離小組和工作負載。 Kubernetes 排程器提供的進階功能可讓您控制哪些 Pod 可以在特定節點上排程。 它們也可讓您控制多腳架應用程式如何適當地分散到叢集。
（工作負載）使用 KEDA，根據工作負載特有的訊號來建置有意義的自動調整規則集。 並非所有規模決策都可以衍生自 CPU 或記憶體計量。 規模考慮通常來自更複雜的甚至外部數據點。 KEDA 可讓您的應用程式根據事件進行調整，例如佇列中的訊息數目或主題延遲的長度。

Azure 原則

Azure 提供一套豐富的內建政策，這些政策適用於 Azure 資源，涵蓋與 AKS 相關的項目，例如一般 Azure 政策和適用於 Kubernetes 的 Azure Policy 附加元件，並應用於叢集內。 許多 Azure 資源原則都 稽核/拒絕，以及 部署 if not exists 變體。 除了內建的 Azure 原則定義之外，您還可以為 AKS 資源和 Kubernetes 的 Azure 原則附加元件建立自定義原則。

本文中的一些建議可透過 Azure 原則進行稽核。 例如，您可以檢查下列叢集原則：

  • 叢集已針對 Pod 規格設定準備或存活健康檢查。
  • Microsoft適用於雲端式原則的 Defender。
  • 驗證模式和設定原則，例如Microsoft Entra ID、RBAC 和停用本機驗證。
  • API 伺服器網路存取原則，包括私人叢集。
  • GitOps 設定原則。
  • 診斷設定原則。
  • AKS 版本限制。
  • 防止命令執行。

您也可以檢查下列叢集和工作負載原則：

  • Kubernetes 叢集 Pod 安全性計劃適用於以 Linux 為基礎的工作負載。
  • 包含 Pod 和容器功能原則，例如 AppArmor、sysctl、安全性上限、SELinux、seccomp、特殊許可權容器，以及自動掛接叢集 API 認證。
  • 掛接、磁碟區驅動程序和文件系統原則。
  • Pod 和容器網路原則，例如主機網路、埠、允許的外部 IP、HTTPS 和內部負載平衡器。
  • 命名空間部署限制。
  • CPU 和記憶體資源限制。

如需全面治理，請檢閱 Kubernetes 和其他可能影響計算層安全性的 Azure 原則內建定義。

Azure Advisor 建議

Azure Advisor 是個人化的雲端顧問，可協助您遵循最佳做法來優化 Azure 部署。 以下是一些建議，可協助您改善 AKS 的可靠性、安全性、成本效益、效能和營運卓越。

相關內容

請考慮下列文章作為資源，用以展示本文所強調的建議。

使用下列產品檔建置實作專業知識：