編輯

共用方式為

Azure Kubernetes Service (AKS) 叢集的基準架構

Azure 應用程式閘道
Azure Container Registry
Azure 防火牆
Azure Kubernetes Service (AKS)
Azure 角色型存取控制

本文提供了部署 Azure Kubernetes 服務 (AKS) 叢集的建議基準基礎結構架構。 它使用我們的設計原則，並基於 Azure 架構完善框架中的 AKS 架構最佳做法。 本文有助於指導多個不同的跨學科小組 (例如網路、安全性和身分識別團隊) 部署此通用基礎設施。

此架構不關注工作負載。 專注於 AKS 叢集本身。 此資訊是大多數 AKS 叢集的最低建議基準。 它與提供可檢視性的 Azure 服務整合，提供支援多區域成長的網路拓撲並保護叢集內流量。

您的業務需求會影響目標架構，並且它可能會因不同的應用程式環境而異。 將架構視為預生產和生產階段的起點。

Kubernetes 是一個強大的生態系統，超越了 Azure 和 Microsoft 技術。 部署 AKS 叢集時，您需要負責做出大量有關如何設計和作業叢集的決策。 執行 AKS 叢集涉及來自各種供應商 (包括 Microsoft) 的閉源元件的組合；以及來自 Kubernetes 生態系統的開源元件。 情況經常發生變化，您可能需要定期重新審視決策。 透過採用 Kubernetes，您就承認您的工作負載需要其功能，並且工作負載團隊已準備好持續投資。

您可以在 GitHub：AKS 基準參考實作上使用此架構的實作。 將其用作替代起點並根據您的需求設定參考架構。

注意

參考架構需要了解 Kubernetes 及其知識。 如果您需要複習，請參閱 Kubernetes 簡介和在 Kubernetes 訓練路徑上開發和部署應用程式。

網路設定

網路拓撲
規劃 IP 位址
部署輸入資源

集群計算

基礎叢集的計算
容器映像引用
原則管理

身分識別管理

整合叢集的 Microsoft Entra ID
為工作負載整合叢集的 Microsoft Entra ID

保護資料流程

保護網路流程
新增秘密管理

業務持續性

延展性
叢集和節點可用性
可用性和多區域支援

Operations

叢集和工作負載 CI/CD 管線
叢集健康情況和計量
成本管理和報告

網路拓撲

該架構使用中樞輻射型網路拓撲。 在透過虛擬網路對等互連的單獨虛擬網路中部署中心和分支。 這種拓樸有幾個優點。 使用此拓撲來：

  • 啟用隔離管理。 您可以應用治理並遵守最小特權原則。 它也支援職責分離的 Azure 登陸區域的概念。

  • 盡量減少 Azure 資源對公用 Internet 的直接暴露。

  • 提供區域中心輻射拓樸。 您可以在未來擴展中心輻射型網路拓撲並提供工作負載隔離。

  • 使用 Web 應用程式防火牆服務協助檢查所有 Web 應用程式的 HTTP 流量。

  • 為跨多個訂閱的工作負載提供支援。

  • 使架構可擴展。 為了適應新功能或工作負載，您可以新增輻條，而不用重新設計網路拓撲。

  • 支援跨網路共享資源，例如防火牆和網域名稱系統 (DNS) 區域。

  • 與 Azure 企業級登陸區域保持一致。

顯示中心輻射型網路拓撲的架構圖。

下載此架構的 Visio 檔案。

有關詳細資訊，請參閱 Azure 中的中心輻射網路拓撲。

關於 AKS 基準參考體系結構上的 Windows 容器中包含的網路設計變更的詳細資訊，請參閱 AKS 上的 Windows 容器。

中樞虛擬網路

中樞虛擬網路是連線能力和可檢視性的中心點。 在此架構中，中樞包含：

  • 具有全域防火牆原則的 Azure 防火牆，由中央 IT 團隊定義，以強制執行組織範圍的防火牆原則。
  • 用於遠端存取虛擬機器 (VM) 的 Azure Bastion。
  • 用於 VPN 連線的閘道子網路。
  • 用於網路可檢視性的 Azure Monitor。

在網路內，此架構有三個子網路。

要裝載 Azure 防火牆的子網路

Azure 防火牆是託管防火牆服務。 Azure 防火牆執行個體可保護出站網路流量。 如果沒有這一層安全性，流量可能會與惡意的非 Microsoft 服務進行通信，從而洩露敏感的工作負載資料。 使用 Azure 防火牆管理員集中部署並設定多個 Azure 防火牆執行個體，並管理此中心虛擬網路架構類型的 Azure 防火牆原則。

要裝載閘道的子網路

此子網路是 VPN 閘道或 Azure ExpressRoute 閘道的佔位符。 此閘道會在內部部署網路中的路由器與虛擬網路之間提供連線。

要裝載 Azure Bastion 的子網路

此子網路是 Azure Bastion 的佔位符。 可以使用 Azure Bastion 安全地存取 Azure 資源，而無需將資源公開至 Internet。 此子網路僅用於管理和操作。

輪輻虛擬網路

輪輻虛擬網路包含 AKS 叢集和其他相關資源。 輻條具有以下子網路。

要裝載 Azure 應用程式閘道的子網路

應用程式閘道是在第 7 層執行的 Web 流量負載平衡器。 參考實作使用啟用 Azure Web 應用程式防火牆的應用程式閘道 v2 SKU。 Web 應用程式防火牆可保護傳入流量免受常見 Web 流量攻擊 (包括機器人攻擊)。 此執行個體具有接收使用者請求的公共前端 IP 設定。 根據設計，應用程式閘道需要專用的子網路。

要裝載輸入資源的子網路

為了路由和分發流量，Traefik 是滿足 Kubernetes 入口資源的入口控制器。 Azure 內部負載平衡器存在於這個子網路中。 關於詳細資訊，請參閱將內部負載平衡器與 AKS 結合使用。

要裝載叢集節點的子網路

AKS 維護兩個節點集區，它們是獨立的節點組。 「系統節點集區」會裝載執行核心叢集服務的 Pod。 「使用者節點集區」會執行您的工作負載和輸入控制器，以啟用對工作負載的輸入通訊。

為 Azure 容器登錄和 Azure Key Vault 建立私人連結連接，以便使用者可以透過分支虛擬網路內的專用終端點存取這些服務。 專用端點不需要專用子網路。 您也可以將專用端點放置在中心虛擬網路中。 在基準實作中，端點部署到分支虛擬網路內的專用子網路。 此方法減少了透過對等網路連接的流量。 它將屬於叢集的資源保留在同一虛擬網路中。 您也可以使用網路安全群組在子網路層級套用精細的安全規則。

如需詳細資訊，請參閱私人連結部署選項。

規劃 IP 位址

顯示 AKS 叢集的網路拓樸的圖

下載此架構的 Visio 檔案。

此參考架構使用多種網路方法，每種方法都需要一個 IP 位址空間：

  • 您的 Azure 虛擬網路，用於叢集節點、專用終端點和應用程式閘道等資源。
  • 此叢集使用 Azure CNI Overlay，它將 IP 位址從單獨的位址空間指派給 Azure 虛擬網路的 Pod。

虛擬網路 IP 位址空間

Azure 虛擬網路的位址空間應足夠大以容納所有子網路。 考慮接收流量的所有實體。 Kubernetes 從子網路位址空間為這些實體指派 IP 位址。 規劃 Azure 虛擬網路的 IP 位址時請考慮這些要點。

  • 升級：AKS 定期更新節點，以確保底層虛擬機器的安全功能和其他系統修補程式是最新的。 在升級過程中，AKS 會建立節點，暫時裝載 Pod，同時升級節點會受到封鎖並清空。 該暫存節點會從叢集子網路獲指派 IP 位址。 確保您有足夠的位址空間來容納這些臨時節點 IP 位址。

    在此體系架構中，Pod 會從 Azure CNI Overlay Pod 位址空間內指派 IP 位址，包括在捲動更新期間。 與其他 Kubernetes 網路方法相比，此方法減少了 Azure 虛擬網路使用的 IP 位址總數。

  • 可擴展性：考慮所有系統和使用者節點的節點數及其最大可擴展性限制。 假設您想要擴增 400%。 所有這些橫向擴展的節點需要四倍的位址數量。

    由於此體系結構使用 Azure CNI Overlay，因此 Pod 的可擴充性不會影響虛擬網路的位址空間。

  • 私人連結位址：考慮透過私人連結與其他 Azure 服務進行通訊所需的位址。 此架構為容器登錄和 Key Vault 的連結指派了兩個位址。

  • 保留的 IP 位址：Azure 保留某些位址供其使用。 他們不能被分配。

前面的列表並不詳盡。 如果您的設計具有影響可用 IP 位址數量的其他資源，請容納這些位址。

此架構是專為單一工作負載所設計。 在生產 AKS 叢集中，始終將系統節點集區與使用者節點集區分開。 當您在叢集上執行多個工作負載時，您可能會想要將使用者節點集區彼此隔離。 當您這樣做時，會產生更多尺寸更小的子網路。 此外，輸入資源可能更複雜，因此您可能需要多個要求額外 IP 位址的輸入控制器。

Pod IP 位址空間

Azure CNI Overlay 使用專用位址空間將 IP 位址指派給 Pod，該位址空間與虛擬網路中使用的位址空間分開。 使用不與虛擬網路或任何對等虛擬網路重疊的 IP 位址空間。 但是，如果建立多個 AKS 叢集，則可以安全地在每個叢集上使用相同的 pod 位址空間。

每個節點都為其 pod 分配一個 /24 位址空間，因此確保 pod 位址空間足夠大以允許叢集中節點數量所需的 /24 區塊非常重要。 請記住包括在升級或橫向擴展操作期間建立的任何臨時節點。 例如，如果您對 CIDR 範圍使用 /16 位址空間，則您的叢集最多可以成長到大約 250 個節點。

每個節點最多支援 250 個 Pod，此限制包括升級期間臨時建立的任何 Pod。

有關詳細資訊，請參閱有關 Azure CNI 覆蓋的 IP 位址規劃的指南

其他 IP 位址空間注意事項

有關此體系結構的完整網路注意事項集，請參閱 AKS 基線網路拓撲。 有關為 AKS 叢集規劃 IP 尋址的資訊，請參閱為叢集規劃 IP 尋址。

有關 AKS 基準參考體系結構上的 Windows 容器中包含的 IP 位址規劃注意事項的詳細資訊，請參閱 AKS 上的 Windows 容器。

附加元件和預覽功能

Kubernetes 和 AKS 不斷發展，發布週期比本地環境的軟體更快。 此基準體系結構取決於選定的 AKS 預覽功能和 AKS 附加元件。 以下是這兩個功能之間的差異：

  • AKS 團隊將預覽功能描述為已發布並正在改進，因為許多預覽功能在進入公開可用性 (GA) 階段之前僅保持該狀態數月。

  • AKS 附加元件和擴充功能提供額外的支援功能。 AKS 管理其安裝、設定和生命週期。

此基準架構並不包含所有預覽功能或附加元件。 相反，它僅包含那些為通用集群增加重要價值的內容。 隨著這些功能不再預覽，此基線架構也會進行相應修改。 您可能想要在預生產叢集中評估一些其他預覽功能或 AKS 附加元件。 這些功能可以提高您的安全性、可管理性或其他要求。 對於非 Microsoft 附加元件，您必須安裝和維護它們，包括追蹤可用版本以及在升級叢集的 Kubernetes 版本後安裝更新。

容器映像引用

除了工作負載之外，叢集還可能包含多個其他映像，例如入口控制器。 其中一些影像可能駐留在公共登錄中。 當您將映像提取到叢集中時，請考慮這些點。

  • 驗證叢集以拉取鏡像。

  • 如果您使用公用映像，請將公用映像匯入至與您的服務等級目標 (SLO) 一致的容器登錄中。 否則，映像可能會出現意外的可用性問題。 如果在您需要時影像不可用，則可能會導致操作問題。 以下是使用私人容器登錄 (例如 Azure 容器登錄) 而不是公共登錄的一些好處：

    • 您可以封鎖對您的影像的未經授權的存取。
    • 您沒有面向公眾的依賴項。
    • 您可以存取映像拉取記錄來監控活動並分類連線問題。
    • 您可以利用整合的容器掃描和映像合規性。

  • 從授權登錄中提取影像。 您可以透過 Azure 原則強制執行此限制。 在此參考實作中，叢集僅從部署的容器登錄執行個體中擷取映像。

設定基底叢集的計算

在 AKS 中，每個節點集區會對應到一個虛擬機器規模集。 節點是每個節點集區中的 VM。 請考慮針對系統節點集區使用較小的 VM 大小，以將成本降到最低。 此參考實作會部署具有三個 DS2_v2 節點的系統節點集區。 該大小足以符合系統 Pod 的預期負載。 作業系統盤為 512 GB。

針對使用者節點集區，以下是一些考量：

  • 選擇較大的節點大小，以封裝節點上設定的 Pod 數目上限。 大型節點最大限度地減少了所有節點上執行的服務 (例如監控和記錄記錄) 的佔用空間。

  • 如果您有特定的工作負載要求，請選擇適當的 VM 類型。 例如，您可能需要針對某些工作負載的記憶體最佳化產品，或針對其他工作負載的 GPU 加速產品。 如需相關資訊，請參閱 Azure 中虛擬機器的大小。

  • 部署至少兩個節點。 如此一來，工作負載具有兩個複本的高可用性模式。 使用 AKS，您可以變更節點數，而不需要重新建立叢集。

  • 根據設計團隊所決定的要求規劃工作負載的實際節點大小。 根據業務需求，此架構使用 DS4_v2 來處理生產工作負載。 為了降低成本，您可以將大小降低到 DS3_v2，這是最低建議。

  • 假設在規劃叢集容量時，您的工作負載消耗每個節點高達 80% 的資源。 剩餘的 20% 保留用於 AKS 服務。

  • 根據您的容量規劃，設定每個節點的 Pod 數目上限。 如果您嘗試建立容量基準，請從值 30 開始。 根據工作負載、節點大小和您的 IP 條件限制式的需求調整該值。

選取作業系統

大多數 AKS 叢集使用 Linux 作為其節點集區的作業系統。 在這個參考實作中，我們使用 Azure Linux，它是一個輕量級、強化的 Linux 發行版，已針對 Azure 進行了調整。 如果您願意，或者您有 Azure Linux 無法滿足的要求，您可以選擇使用其他 Linux 發行版，例如 Ubuntu。

AKS 也支援執行 Windows Server 作業系統的節點集區。 執行 Windows 的叢集的某些方面有特殊要求。 若要了解有關 Windows 節點集區體系結構的更多資訊，請參閱在 AKS 上執行 Windows 容器。

如果您的工作負載由多種技術組成，則可以在不同的節點集區中使用不同的作業系統。 但是，如果您的工作負載不需要不同的作業系統，我們建議您對所有工作負載的節點集區使用單一作業系統。

整合叢集的 Microsoft Entra ID

保護對叢集資源的存取以及叢集對外部資源的存取非常重要。 當您做出安全選擇時，請從叢集的角度考慮：

  • 由內而外的存取。 考慮使用 AKS 存取 Azure 元件，例如網路基礎架構、容器登錄和 Key Vault。 僅授權叢集應允許存取的資源。
  • 由外而內的存取。 提供對 Kubernetes 叢集的身份存取。 只授權那些可以存取 Kubernetes API 伺服器與 Azure Resource Manager 的外部實體。

對 Azure 的 AKS 存取

有兩種方式可透過 Microsoft Entra ID 管理 AKS 對 Azure 的存取：服務主體或 Azure 資源受控識別。

在管理 AKS 對 Azure 的存取的兩種方法中，我們建議使用託管識別。 對於服務主體，您必須手動或以程式方式管理和輪調機密。 透過託管身份，Microsoft Entra ID 可以為您管理和執行身份驗證以及及時輪換機密。

我們建議您啟用並使用託管標識，以便叢集可以透過 Microsoft Entra ID 與外部 Azure 資源互動。 即使您不立即使用 Microsoft Entra ID 整合，也可以稍後將其合併。

預設情況下，叢集使用兩個主要身分：叢集身分和 kubelet 身分。 AKS 控制平面元件使用叢集標識來管理叢集資源，包括入口負載平衡器和 AKS 管理的公共 IP。 kubelet 身分透過容器登錄進行驗證。 某些附加元件還支援使用託管身份進行身份驗證。

當叢集需要從容器登錄中提取映像時，您應該使用託管身分。 此動作要求叢集必須取得登錄的認證。 如果您不使用託管身份，那麼您可以以 Kubernetes 秘密物件的形式儲存該資訊並用於imagePullSecrets擷取秘密。 由於安全複雜性，我們不推薦這種方法。 您不僅需要事先了解該秘密，還需要將該秘密儲存在 DevOps 管線中。 我們不推薦這種方法的另一個原因是管理金鑰輪換的操作開銷。 相反，請將叢集的 kubelet 託管身分的 AcrPull 存取權限授予您的登錄。 這種方法解決了人們的擔憂。

在此體系結構中，叢集存取 Microsoft Entra ID 保護的 Azure 資源，且叢集執行支援託管識別碼的操作。 根據叢集執行的操作，將 Azure 基於角色的存取控制 (Azure RBAC) 和權限指派給叢集的託管識別碼。 叢集向 Microsoft Entra ID 驗證自身身份，然後根據指派給它的角色允許或拒絕存取。 以下是此參考實作中的一些範例，其中將 Azure 內建角色指派給叢集：

  • 網路參與者角色。 管理叢集控制分支虛擬網路的能力。 透過此角色分配，AKS 叢集系統指派的識別可以與內部入口控制器服務的專用子網路搭配使用。

  • 監視計量發行者角色。 管理叢集將指標傳送到 Azure Monitor 的能力。

  • AcrPull 角色。 管理叢集從指定的 Azure 容器登錄執行個體擷取映像的能力。

叢集存取

Microsoft Entra 整合也可簡化由外而內存取的安全性。 例如，您可能想要使用 kubectl。 作為初始步驟，您可以執行az aks get-credentials命令來取得叢集的憑證。 Microsoft Entra ID 會根據允許取得叢集憑證的 Azure 角色來驗證你的身分。 如需詳細資訊，請參閱可用的叢集角色權限。

AKS 透過兩種方式支援使用 Microsoft Entra ID 存取 Kubernetes。 第一種是使用 Microsoft Entra ID 作為與本機 Kubernetes RBAC 系統整合的身分提供者。 另一種方法是使用本機 Azure RBAC 來控制叢集存取。 另一種方法是使用本機 Azure RBAC 來控制叢集存取。

將 Kubernetes RBAC 與 Microsoft Entra ID 關聯

將 Kubernetes RBAC 與 Microsoft Entra ID 關聯

  • 您透過使用 Role 或 ClusterRole 物件來定義叢集範圍權限的一組權限。

  • 分配有權執行操作的使用者和群組的綁定。 使用 RoleBinding 或 ClusterRoleBinding 物件定義綁定。

Kubernetes 有一些內建角色，例如集群管理、編輯和檢視。 將這些角色綁定到 Microsoft Entra 使用者和群組，以使用企業目錄來管理存取。 有關更多資訊，請參閱將 Kubernetes RBAC 與 Microsoft Entra 整合結合使用。

請確保在 Microsoft Entra 存取權檢閱中包含用於叢集和命名空間存取的 Microsoft Entra 群組。

使用適用於 Kubernetes 的 Azure RBAC 授權

我們建議您使用 Azure RBAC 和 Azure 角色分配，而不是使用 Kubernetes 本機 RBAC、ClusterRoleBindings 和 RoleBindings，並透過整合的 Microsoft Entra 驗證進行授權。 此方法對叢集強制執行授權檢查。 您甚至可以在管理群組、訂閱或資源群組範圍內指派這些角色。 然後，該範圍內的所有叢集都會繼承一組一致的角色分配，以決定誰有權存取 Kubernetes 叢集上的物件。

有關詳細資訊，請參閱用於 Kubernetes 授權的 Azure RBAC。

本機帳戶

AKS 支援本機 Kubernetes 使用者驗證。 我們不建議您使用此方法來提供使用者對叢集的存取。 此方法基於憑證並在主要身分提供者外部執行，這使得集中式使用者存取控制和治理變得困難。 始終使用 Microsoft Entra ID 管理對叢集的訪問，並將叢集設定為明確停用本機帳戶存取。

在此參考實作中，當系統部署叢集時，明確停用本機叢集帳戶存取。

為工作負載整合叢集的 Microsoft Entra ID

與整個叢集擁有 Azure 系統指派的託管標識類似，你可以在 Pod 層級指派託管識別碼。 工作負載標識使託管工作負載能夠透過 Microsoft Entra ID 存取資源。 例如，工作負載將檔案儲存在 Azure 儲存體中。 當需要存取這些檔案時，Pod 會針對資源作為 Azure 託管識別碼對自身進行驗證。

在此參考實作中，AKS 上的 Microsoft Entra Workload ID 提供 Pod 的託管識別。 此方法與 Kubernetes 本機功能整合，以與外部身分提供者聯合。 有關 Microsoft Entra 工作負載 ID 聯合的詳細資訊，請參閱工作負載身份聯合。

選擇網路模型

AKS 支援多種網路模型，包括 kubenet、CNI 和 Azure CNI Overlay。 CNI 模型是更先進的模型，並且具有高性能。 當 Pod 之間通訊時，CNI 的效能類似於虛擬網路中 VM 的效能。 CNI 還提供增強的安全控制，因為它支援使用 Azure 網路原則。 我們推薦基於 CNI 的網路模型。

在非覆蓋 CNI 模型中，每個 Pod 從子網路位址空間取得一個 IP 位址。 同一網路內的資源 (或對等資源) 可以透過其 IP 位址直接存取 Pod。 路由該流量不需要網路位址轉換 (NAT)。

在此參考實作中，我們使用 Azure CNI Overlay，它僅從節點集區子網路中為節點指派 IP 位址，並為 Pod IP 使用高度最佳化的覆蓋層。 由於 Azure CNI 覆蓋比許多其他方法使用更少的虛擬網路 IP 位址，因此我們建議將其用於 IP 位址受限的部署。

有關模型的資訊，請參閱選擇要使用的容器網路介面網路模型和比較 kubenet 和 Azure 容器網路介面網路模型。

部署輸入資源

Kubernetes 入口資源處理傳入叢集的流量的路由和分配。 入口資源分為兩部分：

  • 內部負載平衡器，由 AKS 管理。 負載平衡器透過私人靜態 IP 位址公開入口控制器。 它充當接收入站流量的單點聯繫。

    此架構使用 Azure Load Balancer。 Load Balancer 位於專用於輸入資源的子網路叢集之外。 它接收來自應用程式閘道的流量，並且該通訊透過傳輸層安全性 (TLS) 進行。 有關入站流量的 TLS 加密的更多資訊，請參閱入口流量。

  • 入口控制器。 本範例使用 Traefik。 它執行在叢集中的使用者節點集區中。 它從內部負載平衡器接收流量，終止 TLS，並透過 HTTP 將其轉送到工作負載 Pod。

入口控制器是叢集的關鍵元件。 設定此元件時請考慮以下幾點。

  • 作為設計決策的一部分，將入口控制器限制在特定的操作範圍內。 例如，您可能允許控制器僅與執行特定工作負載的 Pod 互動。

  • 避免將副本放置在同一節點上以分散負載，並有助於在節點發生故障時確保業務連續性。 podAntiAffinity 用於此目的。

  • 使用 nodeSelectors 約束 pod 僅在使用者節點集區上調度。 此設定隔離工作負載和系統 Pod。

  • 開啟允許特定實體將流量傳送到入口控制器的連接埠和協定。 在此架構中，Traefik 僅接收來自應用程式閘道的流量。

  • 設定 readinessProbe 和 livenessProbe 設定以指定的時間間隔監控 Pod 的運作狀況。 入口控制器應發送指示 Pod 運作狀況的訊號。

  • 考慮限制入口控制器對特定資源的存取以及執行某些操作的能力。 您可以透過 Kubernetes RBAC 權限來實施此限制。 例如，在此架構中，Traefik 被授予透過使用 Kubernetes ClusterRole 物件中的規則來監視、取得和列出服務和端點的權限。

注意

根據您的要求、工作負載、團隊的技能組合以及技術選項的可支援性選擇合適的入口控制器。 最重要的是，您的入口控制器必須滿足您的 SLO 期望。

Traefik 是 Kubernetes 叢集的開源選項，在此架構中出於說明目的。 它顯示了非 Microsoft 產品與 Azure 服務的整合。 例如，此實作展示如何將 Traefik 與 Microsoft Entra Workload ID 和 Key Vault 整合。

您還可以使用應用程式閘道入口控制器，它與 AKS 整合良好。 除了作為入口控制器的功能外，它還具有其他優點。 例如，應用程式閘道可作為叢集的虛擬網路入口點。 它可以觀察進入叢集的流量。 如果您有需要 Web 應用程式防火牆的應用程式，請使用應用程式閘道。 此外，應用程式閘道還允許您執行 TLS 終止。

有關基準參考體系結構中 AKS 上的 Windows 容器的入口設計的詳細資訊，請參閱 AKS 上的 Windows 容器。

路由器設定

入口控制器使用路由來確定將流量傳送到哪裡。 路由指定接收流量的來源連接埠以及有關目標連接埠和協定的資訊。

以下是該架構的範例：

Traefik 使用 Kubernetes 提供者來設定路由。 annotations、 tls 和 entrypoints 選項指示透過 HTTPS 提供路由。 此 middlewares 選項指定僅允許來自應用程式閘道子網路的流量。 如果客戶端接受，回應將使用 gzip 編碼。 由於 Traefik 執行 TLS 終止，因此與後端服務的通訊是透過 HTTP 進行的。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

保護網路流程

在該架構中，網路流程包括：

  • 從客戶端到叢集中執行的工作負載的入口流量。

  • 從叢集中的 Pod 或節點到外部服務的出口流量。

  • Pod 之間的 Pod 到 Pod 流量。 此流量包括輸入控制器與工作負載之間的通訊。 如果您的工作負載由部署到叢集的多個應用程式組成，那麼這些應用程式之間的通訊也屬於此類。

  • 客戶端和 Kubernetes API 伺服器之間的管理流量。

顯示集群流量的圖表。

下載此架構的 Visio 檔案。

此架構有數層安全性可保護所有類型的流量。

輸入流量流程

架構只接受來自用戶端的 TLS 加密要求。 TLS v1.2 是允許的最低版本，具有一組受限的密碼。 啟用伺服器名稱指示 (SNI) 嚴格匹配。 端對端 TLS 是透過應用程式閘道使用兩個不同的 TLS 憑證設定的，如下圖所示。

顯示 TLS 終止的圖表。

下載此架構的 Visio 檔案。

  1. 客戶端向網域發送HTTPS請求：bicycle.contoso.com 此名稱與應用程式閘道的公共 IP 位址的 DNS A 記錄相關聯。 此流量經過加密，有助於確保用戶端瀏覽器和閘道之間的流量無法被檢查或變更。

  2. 應用程式閘道具有整合的 Web 應用程式防火牆，並協商 bicycle.contoso.com TLS 握手，僅允許安全密碼。 應用程式閘道是 TLS 終止點，這很重要，因為應用程式閘道的 Web 應用程式防火牆需要檢查明文回應。 Key Vault 儲存 TLS 憑證。 叢集使用與應用程式閘道整合的使用者分配的託管標識來存取它。 如需詳細資訊，請參閱使用 Key Vault 憑證終止 TLS。

    應用程式閘道處理 Web 應用程式防火牆檢查規則並執行將流量轉送至設定的後端的路由規則。

  3. 當流量從應用程式閘道移動到後端時，它會使用另一個 TLS 憑證再次加密，該憑證是 *.aks-ingress.contoso.com 的通配符，因為它會轉送到內部負載平衡器。 這種重新加密有助於確保不安全的流量不會流入叢集子網路。

  4. 輸入控制器會透過負載平衡器接收加密的流量。 控制器是另一個 *.aks-ingress.contoso.com TLS 終止點，並透過 HTTP 將流量轉送到工作負載 Pod。 憑證儲存在 Key Vault 中，容器儲存體介面 (CSI) 驅動程式將它們安裝到叢集中。 如需詳細資訊，請參閱新增用戶端密碼管理。

您可以透過工作負載 Pod 在每一跳實作端對端 TLS 流量。 在做出保護 Pod 到 Pod 流量的決定時，請務必衡量效能、延遲和操作影響。 對於大多數單租戶集群，透過適當的控制平面 RBAC 和成熟的軟體開發生命週期實踐，對入口控制器進行 TLS 加密並使用 Web 應用程式防火牆進行保護就足夠了。 這種方法最大限度地減少了工作負載管理的開銷以及由於網路效能較差而產生的開銷。 您的工作負載和合規性要求決定了您在何處執行 TLS 終止。

出口流量

在此體系結構中，我們建議來自叢集的所有出口流量都透過 Azure 防火牆進行通訊。 或者您可以使用自己的類似網路虛擬設備。 我們不建議使用其他出口選項，例如 Azure NAT 閘道或 HTTP 代理，因為它們不提供網路流量檢查。 為了實現零信任控制和檢查流量的能力，來自叢集的所有出口流量都通過防火牆。 您可以使用使用者定義的路由 (UDR) 來實現此設定。 路由的下一個躍點是 Azure 防火牆的私人 IP 位址。 Azure 防火牆決定是封鎖還是允許出口流量。 這個決定是基於你在 Azure 防火牆中定義的特定規則或內建威脅情報規則。

Azure 防火牆的替代方法是使用 AKS HTTP 代理功能。 離開叢集的所有流量都會傳送到 HTTP 代理的 IP 位址，該代理會轉送流量或丟棄流量。

對於任一方法，請查看 AKS 所需的出口網路流量規則。

注意

如果您使用公共負載平衡器作為通過使用 UDR 的防火牆的入口流量和出口流量的公共點，您可能會看到不對稱路由情況。 此體系結構在應用程式閘道後面的專用入口子網路中使用內部負載平衡器。 這種設計選擇不僅增強了安全性，而且消除了不對稱路由問題。 或者，您可以在應用程式閘道之前或之後透過防火牆路由入口流量，但這種方法在大多數情況下不是必需的，我們也不建議這樣做。 有關非對稱路由的詳細資訊，請參閱將防火牆與 Azure 標準負載平衡器整合。

零信任控制的例外是當叢集需要與其他 Azure 資源通訊時。 例如，叢集可能需要從容器登錄中提取更新的映像或從 Key Vault 中提取機密。 在這些場景中，我們建議您使用私人連結。 優點是特定子網路直接到達服務，且叢集和服務之間的流量不會透過網際網路。 缺點是私人連結需要額外的設定，而不是透過其公共端點使用目標服務。 此外，並非所有 Azure 服務或產品都支援私人連結。 對於這些情況，請考慮啟用子網路上的虛擬網路服務端點來存取該服務。

如果無法選擇私人連結或服務端點，則可以透過公共終結點存取其他服務，並透過 Azure 防火牆規則和目標服務內建的防火牆控制存取。 由於此流量通過防火牆的靜態 IP 位址，因此您可以將這些位址新增至服務的 IP 允許清單中。 一個缺點是 Azure 防火牆需要更多規則來確保它只允許來自特定子網路的流量。 當你使用 Azure 防火牆為出口流量規劃多個 IP 位址時，請考慮這些位址。 否則，您可能會遇到連接埠耗盡的情況。 有關規劃多個 IP 位址的詳細資訊，請參閱建立具有多個 IP 位址的 Azure 防火牆。

有關 AKS 基準參考體系結構上的 Windows 容器中特定於 Windows 的出口注意事項的資訊，請參閱 AKS 上的 Windows 容器。

Pod 到 Pod 流量

預設情況下，Pod 可以接受來自叢集中任何其他 Pod 的流量。 使用 Kubernetes NetworkPolicy 限制 Pod 之間的網路流量。 明智地應用原則，否則您可能會遇到關鍵網路流量被阻止的情況。 僅根據需要允許特定的通訊路徑，例如入口控制器和工作負載之間的流量。 如需詳細資訊，請參閱網路原則。

在設定叢集時啟用網路原則，因為以後無法新增它。 您可以選擇多種技術來實現 NetworkPolicy。 我們建議使用 Azure 網路原則，這需要 Azure 容器網路介面 (CNI)。 如需詳細資訊，請參閱下列筆記。 其他選項包括 Calico 網路原則，這是一個著名的開源選項。 如果您需要管理叢集範圍的網路原則，請考慮 Calico。 標準 Azure 支援不涵蓋 Calico。

關於詳細資訊，請參閱 Azure 網路原則引擎之間的差異。

管理流量

作為執行叢集的一部分，Kubernetes API 伺服器接收來自想要在叢集上執行管理作業的資源的流量，例如建立資源以擴展叢集的請求。 這些資源的範例包括 DevOps 管線中的建置代理程式集區、Azure Bastion 子網路中的 Azure Bastion 執行個體以及節點集區本身。 不要接受來自所有 IP 位址的管理流量，而是使用 AKS 授權的 IP 範圍功能僅允許從授權 IP 範圍到 API 伺服器的流量

有關更多資訊，請參閱定義 API 伺服器授權的 IP 範圍。

對於另一層控制，您可以設定私有 AKS 集群，但會增加額外的複雜度。 透過使用私有集群，您可以協助確保 API 伺服器和節點集區之間的網路流量僅保留在私有網路上，並且永遠不會暴露在 Internet 上。 如需詳細資訊，請參閱 AKS 私人集群。

新增秘密管理

將機密儲存在託管金鑰儲存中，例如 Key Vault。 優點是託管金鑰儲存可以處理秘密的輪換。 它提供強大的加密和存取稽核記錄。 它還將核心秘密保留在部署管線之外。 在此架構中，啟用並設定了 Key Vault 防火牆，並在從 Azure 中需要存取機密和憑證的資源進行連線時使用私人連結。

Key Vault 與其他 Azure 服務完美整合。 使用這些服務的內建功能來存取機密。 有關應用程式閘道如何存取入口流的 TLS 憑證的詳細資訊，請參閱入口流量部分。

Key Vault 的 Azure RBAC 權限模型可讓你將工作負載身分識別指派給 Key Vault 機密使用者或 Key Vault 讀取者角色分配，並存取機密。 有關詳細資訊，請參閱使用 RBAC 存取金鑰。

存取叢集機密

您需要使用工作負載身分識別來允許 Pod 存取特定儲存中的機密。 為了促進檢索過程，請使用機密儲存 CSI 驅動程式。 當 Pod 需要機密時，驅動程式會與指定的儲存連接，檢索磁碟區上的機密，並將該磁碟區掛載到叢集中。 然後 Pod 可以從磁碟區檔案系統取得秘密。

CSI 驅動程式有許多提供者來支援各種託管儲存。 此實作使用帶有機密儲存 CSI 驅動程式的 Key Vault。 此附加元件從 Key Vault 檢索 TLS 證書，並將驅動程式載入到執行入口控制器的 Pod 中。 此操作發生在 Pod 建立期間，磁碟區儲存公鑰和私鑰。

工作負載儲存體

此架構中的工作負載是無狀態的。 如果您需要儲存狀態，我們建議將其保留在叢集之外。 工作負載狀態指南不屬於本文的討論範圍。

如需詳細資訊，請參閱 AKS 中的應用程式適用的儲存體選項。

原則管理

管理 AKS 叢集的有效方法是透過原則實施治理。 Kubernetes 透過開放式原則代理程式 (OPA) Gatekeeper 實作原則。 對於 AKS，透過 Azure Policy 交付政策。 每個原則適用於其範圍內的所有叢集。 OPA Gatekeeper 處理叢集中的原則實作並記錄所有原則檢查。 原則變更不會立即反映在您的叢集中，因此預計會出現一些延遲。

要管理 AKS 叢集，可以使用 Azure 原則來：

  • 防止或限制在資源組或訂閱中部署 AKS 叢集。 為您的組織應用標準。 例如，您可以遵循命名約定或指定標籤。
  • 透過 Azure Policy for Kubernetes 保護 AKS 叢集。

設定原則時，請根據工作負載的要求套用它們。 考量下列因素：

  • 您想要設定一系列原則 (也稱為計畫) 還是選擇單一原則？ Azure 原則提供兩種內建計畫：基本計畫和限制計畫。 每個計劃都是適用於 AKS 叢集的內建原則的集合。 我們建議您選擇一個計畫 和 ，並為叢集和與叢集互動的資源 (例如容器登錄、應用程式閘道或 Key Vault) 選擇其他原則。 根據您組織的要求選擇原則。

  • 您想要稽核還是拒絕該操作？ 在稽核模式下，允許執行該操作，但會被標記為不合規。 制定流程定期檢查不合規狀態並採取必要的措施。 在拒絕模式下，操作將被阻止，因為它違反了原則。 選擇此模式時要小心，因為它對於工作負載的運作可能限制太多。

  • 您的工作負載中是否存在不應符合設計要求的區域？ Azure 原則能夠指定免於執行原則的 Kubernetes 命名空間。 我們建議您仍然在稽核模式下套用原則，以便您了解這些執行個體。

  • 您是否有內建原則未涵蓋的要求？ 您可以建立應用自訂 OPA Gatekeeper 政策的自訂 Azure 政策定義。 不要將自訂原則直接套用至叢集。 有關詳細資訊，請參閱建立和指派自訂原則定義。

  • 您有組織範圍內的要求嗎？ 如果是這樣，請在管理群組層級新增這些原則。 即使您的組織有通用原則，您的叢集也應該分配自己的特定於工作負載的原則。

  • 您是否將 Azure 原則指派給特定範圍？ 確保生產原則也根據您的預生產環境進行驗證。 否則，部署到生產環境時，您可能會遇到在預生產中未考慮到的意外額外限制。

此參考實作會在建立 AKS 叢集時啟用 Azure 原則。 限制性措施在稽核模式下分配，以了解不合規情況。

該實施還制定了不屬於任何內建計劃的額外政策。 這些原則是在拒絕模式下設定的。 例如，有一項政策可確保僅從已部署的容器登錄執行個體中提取映像。 考慮建立您自己的自訂計劃。 將適用於您的工作負載的原則合併到單一分配中。

要觀察 Azure 原則如何在叢集內發揮作用，您可以存取gatekeeper-system命名空間中所有 Pod 的 Pod 記錄azure-policy以及命名空間中 azure-policy-webhook 和 kube-system Pod 的記錄。

有關 Windows 的 Azure 原則注意事項的詳細資訊，請參閱 AKS 原則管理上的 Windows 容器一文。

節點和 Pod 延展性

隨著需求的增加，Kubernetes 可以透過水平 Pod 自動縮放為現有節點添加更多 Pod 來擴展。 當 Kubernetes 無法再調度更多 pod 時，必須透過 AKS 叢集自動縮放來增加節點數量。 完整的縮放解決方案必須有方法可調整叢集中的 Pod 複本和節點計數。

有兩種方法: 自動調整或手動縮放。

自動縮放和手動方法都要求您監視 CPU 使用率或自訂指標並設定警報。 對於 Pod 擴展，您的應用程式操作員可以透過調整 ReplicaSet Kubernetes API 來增加或減少 Pod 副本的數量。 對於叢集擴展，一種方法是在 Kubernetes 調度程序失敗時收到通知。 另一種方式是監看擱置的 Pod 一段時間。 可以透過 Azure CLI 或 Azure 入口網站調整節點計數。

我們建議使用自動縮放方法，因為其中一些手動機制內建於自動縮放器中。

作為一般方法，首先使用最少數量的 Pod 和節點進行效能測試。 使用這些值來建立基線期望值。 然後，結合使用效能指標和手動擴展來定位瓶頸並了解應用程式對擴展的反應。 最後，使用此資料設定自動縮放的參數。 有關使用 AKS 的效能調優方案的詳細資訊，請參閱效能調優方案：分散式業務事務。

水平 Pod 自動調整程式

Horizontal Pod Autoscaler (HPA) 是一種可擴展 Pod 數量的 Kubernetes 資源。

在 HPA 資源中，我們建議設定最小和最大副本計數。 這些值限制自動縮放範圍。

HPA 可根據 CPU 使用率、記憶體使用率和自訂指標進行擴充。 僅提供開箱即用的 CPU 使用情況。 此 HorizontalPodAutoscaler 定義指定了指標的目標值。 例如，規格設定了目標 CPU 使用率。 當 Pod 運作時，HPA 控制器使用 Kubernetes Metrics API 來檢查每個 Pod 的 CPU 使用情況。 它將該值與目標使用量進行比較並計算比率。 然後，它會使用比率來判斷 Pod 是否過度分派或分派不足。 它依賴 Kubernetes 排程器，將新的 Pod 指派給節點，或從節點移除 Pod。

可能存在競爭條件，HPA 在擴展操作完成之前進行檢查。 結果可能是錯誤的比率計算。 有關更多資訊，請參閱擴展事件的冷卻時間。

如果您的工作負載是事件驅動的，那麼流行的開源選項是 Kubernetes 事件驅動自動擴展 (KEDA)。 如果事件來源 (例如訊息佇列) 驅動您的工作負載，而不是受 CPU 限製或記憶體限制的工作負載，請考慮使用 KEDA。 KEDA 支援許多事件來源或縮放器。 使用 KEDA 可以在 KEDA 縮放器上縮放的事件來源清單。 此清單包括 Azure 監視器縮放器，這是一種基於 Azure 監視器指標縮放 KEDA 工作負載的便捷方法。

叢集自動調整程式

叢集自動調整程式 是 AKS 附加元件，可調整節點集區中的節點數目。 在叢集設定期間新增它。 針對每個使用者節點集區，您需要個別的叢集自動調整程式。

Kubernetes 排程器觸發叢集自動縮放程式。 當 Kubernetes 排程器因為資源限制而無法排程 Pod 時，自動調整程式會自動在節點集區中佈建新的節點。 相反地，叢集自動調整程式會檢查節點的未使用容量。 如果節點未以預期的容量執行，Pod 會移至另一個節點，並移除未使用的節點。

啟用自動縮放程式時，設定最大和最小節點數。 建議的值取決於工作負載的效能預期、您希望叢集成長多少，以及成本影響。 最小數目是該節點集區的保留容量。 在此參考實作中，由於工作負載的簡單性，最小值設定為 2。

對於系統節點集區，建議的最小值為 3。

有關此基準參考體系結構中包含的特定於 Windows 的擴展注意事項的資訊，請參閱 AKS 上的 Windows 容器一文。

業務連續性決策

為了保持業務連續性，請為基礎架構和應用程式定義 SLO。 有關詳細資訊，請參閱定義可靠性目標的建議。 在最新的線上服務 SLA 文章中查看 AKS 的服務等級協定 (SLA) 條件。

叢集節點

為了滿足工作負載的最低可用性級別，您需要在節點集區中包含多個節點。 如果一個節點發生故障，則同一節點集區和叢集中的另一個節點可以繼續執行應用程式。 為了可靠性，我們建議系統節點集區為三個節點。 對於使用者節點集區，起始節點不少於兩個。 如果需要更高的可用性，請佈建更多節點。

透過將應用程式放置在單獨的節點集區 (稱為使用者節點集區) 中，將應用程式與系統服務隔離。 這樣，Kubernetes 服務就可以在專用節點上執行，並且不會與您的工作負載競爭。 我們建議您使用標記、標籤和污點來識別節點集區並安排工作負載。 確保您的系統節點集區受到CriticalAddonsOnly污點的污染。

叢集的定期維護 (例如及時更新) 對於可靠性至關重要。 此外，我們建議您透過偵測器監控 Pod 的運作狀況。

Pod 可用性

指定 Pod 資源需求：我們建議您在部署中指定 Pod 資源需求。 然後排程器可以適當地調度 Pod。 如果無法安排您的 Pod，可靠性會大大降低。

設定 Pod 中斷預算：此設定決定在更新或升級事件期間部署中可以關閉的副本數量。 有關更多資訊，請參閱 Pod 中斷預算。

在部署中設定多個副本以處理硬體故障等中斷。 對於更新和升級等計劃事件，中斷預算可以幫助確保存在所需數量的 Pod 副本來處理預期的應用程式負載。

在工作負載命名空間上設定資源配額：命名空間上的資源配額有助於確保部署上正確設定 Pod 請求和限制。 如需詳細資訊，請參閱執行資源配額。

注意

如果您在叢集層級設定資源配額，則在部署沒有適當請求和限制的第三方工作負載時可能會出現問題。

設定 pod 請求和限制：設定請求和限制使 Kubernetes 能夠有效率地將 CPU 和記憶體資源分配給 pod，並讓您在節點上擁有更高的容器密度。 請求和限制還可以提高可靠性，同時由於更好的硬體使用而降低成本。

若要估計工作負載的限制，請測試並建立基準。 從請求和限制的相同值開始。 然後，逐漸調整這些值，直到建立一個可能導致叢集不穩定的閾值。

您可以在部署清單中指定請求和限制。 有關更多資訊，請參閱設定 pod 請求和限制。

可用性區域和多區域支持

為了防止某些類型的中斷，請使用可用性區域 (如果區域支援)。 然後，控制平面元件和節點集區中的節點都能夠跨區域分佈。 如果整個可用性區域不可用，則該區域內另一個可用性區域的節點仍然可用。 每個節點集區映射到一個單獨的虛擬機器規模集，用於管理節點執行個體和可擴展性。 AKS 服務管理規模集操作與設定。 以下是啟用多個區域時的一些注意事項：

  • 整個基礎設施：選擇支援可用性區域的區域。 如需詳細資訊，請參閱限制。 要獲得正常執行時間 SLA，您需要選擇標準層或高級層。 使用可用性區域時，正常運作時間 SLA 會更長。

  • 叢集：只能在建立節點集區時設定可用性區域。 以後無法更改。 所有區域都應支援節點大小，以便可以實現預期的分佈。 底層虛擬機器規模集跨區域提供相同的硬體設定。

    多區域支援不僅適用於節點集區，也適用於控制平面。 AKS 控制平面跨越請求的區域，例如節點集區。 如果您不在叢集中使用區域支持，則無法保證控制平面元件分佈在可用性區域域中。

  • 相關資源：為了獲得完整的區域優勢，所有服務依賴項也必須支援區域。 如果依賴服務不支援區域，則區域故障可能會導致該服務失敗。

    例如，託管磁碟在佈建它的區域中可用。 如果發生故障，節點可能會移動到另一個區域，但託管磁碟不會隨節點移動到該區域。

為了簡化此體系結構，AKS 部署到具有跨可用性區域一、二和三的節點集區的單一區域。 基礎架構的其他資源 (例如 Azure 防火牆和應用程式閘道) 也部署到相同區域並支援多區域。 為容器登錄啟用異地複寫。

多個區域

當您啟用可用性區域時，在整個區域發生故障 (不太可能發生) 的情況下，它的覆蓋範圍不夠。 為了獲得更高的可用性，請在不同區域執行多個 AKS 叢集。

  • 首選配對區域 (如果可用)。 使用配對區域的一個好處是平台更新期間的可靠性。 Azure 確保一次僅更新該對中的一個區域。 有些地區沒有配對。 如果您的區域未配對，您仍然可以透過選擇要使用的其他區域來部署多區域解決方案。 考慮使用持續整合和持續交付 (CI/CD) 管線，您可以將其設定為協調從區域故障中進行恢復。 某些 DevOps 工具 (例如 Flux) 可以讓多區域部署變得更容易。

  • 如果 Azure 資源支援異地冗餘，請提供冗餘服務具有輔助執行個體的位置。 例如，透過為容器登錄啟用異地複寫，它會自動將映像複製到選取的 Azure 區域。 即使主要區域出現中斷，它也可以提供對影像的持續存取。

  • 根據您的要求，選擇可以跨區域或區域分配流量的流量路由器。 此架構部署 Load Balancer，因為它可以跨區域分配非 Web 流量。 如果需要跨區域分配流量，請考慮 Azure Front Door。 如需其他選項，請參閱選擇 Load Balancer。

注意

多區域叢集參考架構的 AKS 基準擴展了本文中的架構，以在主動/主動和高可用設定中包含多個區域。

使用多區域架構的實作作為起點，並根據您的需求進行設定。

災害復原

如果主要區域發生故障，理想情況下，您可以快速在另一個區域建立新執行個體。 以下是一些建議：

  • 使用多個區域。 如果您的主要區域有配對區域，請使用該對。 如果沒有，請根據您的資料駐留和延遲要求選擇區域。

  • 使用可以高效率複製的無狀態工作負載。 如果您需要在叢集中儲存狀態 (我們不建議這樣做)，請確保經常在其他區域備份資料。

  • 將復原原則 (例如複製到另一個區域) 整合為 DevOps 管線的一部分，以滿足您的 SLO。

  • 使用支援災難復原的功能預先配配每個 Azure 服務。 例如，在此架構中，啟用了容器登錄進行異地複寫。 如果某個區域發生故障，您仍然可以從複製的區域中拉取鏡像。

  • 將基礎架構部署為程式碼，包括 AKS 叢集和您需要的任何其他元件。 如果您需要部署到其他區域，您可以重複使用腳本或範本來建立相同的執行個體。

叢集備份

對於許多架構，您可以設定一個新集群，並透過基於 Git 操作的集群啟動程序將其返回到操作狀態，然後進行應用程式部署。 但是，如果存在無法在開機過程中擷取的關鍵資源狀態 (例如組態對應、作業和機密)，請考慮您的復原原則。 我們建議您在 Kubernetes 中執行無狀態工作負載。 如果您的體系結構涉及基於磁碟的狀態，您還必須考慮該內容的復原原則。

當叢集備份必須成為您的復原原則的一部分時，您需要在叢集內安裝符合您的業務需求的解決方案。 此代理程式負責將叢集資源狀態推送到您選擇的目標並協調基於 Azure 磁碟的永續性磁碟快照。

VMware Velero 是您可以直接安裝和管理的常見 Kubernetes 備份解決方案的範例。 或者，您可以使用 AKS 備份擴充功能來提供託管 Velero 實作。 AKS 備份擴充功能支援備份 Kubernetes 資源和持久性卷，並在 Azure 備份中將排程和備份範圍外部化為保管庫設定。

參考實作不會實現備份，這涉及額外的 Azure 資源來管理、監視、購買和保護。 這些資源可能包括 Azure 儲存體帳戶、Azure 備份保管庫和設定以及可信任存取功能。 相反，Git 操作與執行無狀態工作負載的意圖相結合才是恢復解決方案。

選擇並驗證符合您的業務目標的備份解決方案，包括您定義的復原點目標和復原時間目標。 在團隊操作手冊中定義您的復原流程，並針對所有關鍵業務工作負載進行實務。

Kubernetes API 伺服器 SLA

您可以將 AKS 作為免費服務使用，但該層不提供經濟支援的 SLA。 要獲得 SLA，您必須選擇標準層。 我們建議所有生產集群都使用標準層。 為預生產叢集保留免費層，僅為關鍵任務工作負載保留高階層。 當您使用 Azure 可用性區域時，Kubernetes API 伺服器 SLA 會更高。 您的節點集區和其他資源都包含在各自的 SLA 中。 有關每項服務的特定 SLA 的更多資訊，請參閱線上服務的 SLA。

權衡取捨

跨區域 (尤其是區域) 部署架構需要在成本與可用性之間進行權衡。 一些複製功能 (例如容器登錄中的異地複寫) 可在高級 SKU 中使用，但價格更高。 對於多區域部署，成本也會增加，因為流量跨區域移動時會產生頻寬費用。

此外，預計區域或區域之間的節點通訊會出現額外的網路延遲。 衡量此架構決策對您的工作負載的影響。

透過模擬和強制故障轉移進行測試

透過模擬中斷的強制故障轉移測試來測試解決方案的可靠性。 模擬可以包括停止節點、關閉特定區域中的所有 AKS 資源以模擬區域故障或呼叫外部依賴項故障。 也可以使用 Azure Chaos Studio 模擬 Azure 和叢集上的各種類型的中斷。

如需詳細資訊，請參閱 Chaos Studio。

監控和收集指標

我們建議使用 Azure Monitor 容器深入解析來監視容器工作負載的效能，因為您可以即時查看事件。 它從正在執行的 Pod 擷取容器記錄並將其聚合以供查看。 它還從指標 API 收集有關記憶體和 CPU 使用情況的資訊，以監控執行資源和工作負載的執行狀況。 您也可以使用容器深入解析來監控 Pod 擴充時的效能。 它包括對所收集資料的監控、分析和視覺化至關重要的遙測技術。 容器深入解析可識別趨勢，並使您能夠設定警報以接收有關關鍵問題的主動通知。

Pod 中託管的大多數工作負載都會發出 Prometheus 指標。 容器深入解析可以與 Prometheus 整合。 您可以查看從節點和 Kubernetes 收集的應用程式和工作負載指標。

一些非 Microsoft 解決方案與 Kubernetes 整合，例如 Datadog、Grafana 或 New Relic。 因此，如果您的組織已經使用這些解決方案，您就可以利用它們。

Azure 透過 AKS 管理一些核心 Kubernetes 服務。 Azure 將 AKS 控制平面元件的記錄實作為資源記錄。 我們建議您在大多數叢集上啟用以下選項。 這些選項可以幫助您解決叢集問題，並且它們的記錄密度相對較低。

  • ClusterAutoscaler：透過記錄記錄獲得縮放操作的可檢視性。 有關更多資訊，請參閱檢索叢集自動縮放程序記錄和狀態。
  • KubeControllerManager：獲得對 Kubernetes 和 Azure 控制平面之間互動的可檢視性。
  • kube-audit-admin：獲得對修改集群的活動的可檢視性。 沒有理由同時啟用 kube-audit 和 kube-audit-admin。 kube-audit 是 kube-audit-admin 的超集，也包含非修改 (讀取) 操作。
  • guard：擷取 Microsoft Entra ID 和 Azure RBAC 稽核。

在早期叢集或工作負載生命週期開發期間，啟用其他記錄類別 (例如 KubeScheduler 或 kube-audit)可能會對您有所幫助。 新增的叢集自動擴展、Pod 放置和調度以及類似資料可以幫助您解決叢集或工作負載操作問題。 但是，如果在故障排除需求結束後繼續保留擴展故障排除記錄，則可能會因在 Azure Monitor 中提取和儲存資料而產生不必要的成本。

雖然 Azure Monitor 包含一組現有的記錄查詢，但你也可以使用它們作為基礎來幫助建立自己的查詢。 隨著庫的成長，您可以使用一個或多個查詢套件來儲存和重複使用記錄查詢。 自訂查詢庫提供了對 AKS 叢集的運作狀況和效能的更多可檢視性。 它支援實作您的 SLO。

有關 AKS 監視最佳做法的詳細資訊，請參閱使用 Azure Monitor 監視 AKS。

有關特定於 Windows 的監視注意事項的詳細資訊，請參閱 AKS 上的 Windows 容器。

人際網路計量

基本的集群級網路指標可透過本機平台和 Prometheus 指標取得。 您可以進一步使用網路可檢視性外掛程式來公開節點層級的網路指標。 大多數叢集應使用階網路可檢視性外掛程式來提供額外的網路故障排除功能，並偵測節點層級的意外網路使用或問題。

對於對傳輸控制協定 (TCP) 或使用者資料封包協定 (UDP) 資料包遺失、延遲或 DNS 壓力高度敏感的工作負載，Pod 等級網路指標非常重要。 在 AKS 中，您可以透過進階網路可檢視性功能找到該等級的詳細資訊。 大多數工作負載不需要這種深度的網路可檢視性。 除非您的 Pod 需要高度優化的網路，且靈敏度低至資料包級別，否則不應安裝高級網路可檢視性附加元件。

啟用自我修復

透過設定活性和整備度探查來監控 Pod 的運作狀況。 如果 Kubernetes 偵測到一個無回應的 Pod，它會重新啟動該 Pod。 活躍度探查可確定 Pod 是否健康。 如果 Kubernetes 偵測到一個無回應的 Pod，它會重新啟動該 Pod。 整備度探查確定 Pod 是否準備好接收請求和流量。

注意

AKS 具有自動節點修復功能，可為基礎架構節點提供內建的自我修復功能。

AKS 叢集的例行更新

Kubernetes 叢集第二天操作的一部分是執行例行平台和作業系統更新。 每個 AKS 叢集都需要三層更新：

  • Kubernetes 版本 (例如 Kubernetes 1.30.3 至 1.30.7 或 Kubernetes 1.30.7 至 1.31.1)，可能會隨 Kubernetes API 變更和棄用一起提供。 這一層的版本變更會影響整個叢集。
  • 每個節點上的虛擬硬碟 (VHD) 映像，結合了作業系統更新和 AKS 元件更新。 這些更新針對叢集的 Kubernetes 版本進行了測試。 此層的版本變更將應用於節點集區級別，不會影響 Kubernetes 版本。
  • 作業系統本身的本機更新過程，例如 Windows Update 或 apt。 作業系統供應商直接提供這些更新，並且沒有針對叢集的 Kubernetes 版本進行測試。 此層版本變更會影響單一節點，不影響 Kubernetes 版本。

這些層中的每一層都是獨立控制的。 您可以決定如何處理工作負載叢集的每一層。 選擇每個 AKS 叢集、其節點集區或其節點的更新頻率 (節奏)。 另外，選擇套用更新的日期或時間 (維護時段)。 選擇是手動安裝還是自動安裝更新，或者根本不安裝。 就像在叢集上執行的工作負載需要安全的部署實務一樣，叢集的更新也是如此。

有關修補和升級的全面視角，請參閱 AKS 第 2 天操作指南中的 AKS 修補和升級指南。 使用以下資訊作為與此架構相關的基準建議。

不可變的基礎結構

將 AKS 叢集作為不可變基礎設施執行的工作負載不會自動或手動更新其叢集。 設定節點鏡像升級為 none，叢集自動升級為 none。 在此設定中，您全權負責所有層的所有升級。 當您需要的更新可用時，您必須在預生產環境中測試該更新並評估其在新叢集上的相容性。 之後，部署包含更新的 AKS 版本和節點集區 VHD 的生產副本標記。 當新的生產集群準備就緒時，舊集群將被耗盡並最終退役。

定期部署新基礎架構的不可變基礎架構是生產叢集不應應用就地升級原則的唯一情況。 所有其他叢集都應該有就地升級原則。

就地升級

不將 AKS 叢集作為不可變基礎設施執行的工作負載應定期更新其正在執行的叢集，以解決所有三個層的問題。 讓您的更新流程與工作負載的要求保持一致。 使用以下建議作為設計例行更新流程的起點。

  • 安排 AKS 的計劃維護功能，以便您可以控制叢集上的升級。 此功能使您能夠在受控時間執行更新 (本質上是有風險的操作)，以減少意外故障的影響。
  • 設定 Pod 中斷預算，以便您的應用程式在滾動升級期間保持穩定。 但不要將預算設定過於激進，以免阻止節點升級的發生，因為大多數升級都需要在每個節點上進行警戒和排空過程。
  • 確認 Azure 資源配額和資源可用性。 就地升級會在刪除舊節點之前部署新的節點執行個體 (稱為激增節點)。 這意味著 Azure 配額和 IP 位址空間必須可用於新節點。 對於大多數工作負載來說，33% 的激增值是一個很好的起點。
  • 測試與工具的兼容性，例如新增至叢集的服務網格或安全代理程式。 並測試您的工作負載元件，例如入口控制器、服務網格和工作負載 Pod。 在預生產環境中進行測試。
節點就地升級

使用 NodeImage 自動升級頻道進行節點作業系統映像升級。 此通道將您的叢集設定為使用節點級更新來更新每個節點上的 VHD。 Microsoft 針對您的 AKS 版本測試更新。 對於 Windows 節點，更新大約每月一次。 對於 Linux 節點，這些更新大約每週發生一次。

  • 升級永遠不會改變您的 AKS 或 Kubernetes 版本，因此 Kubernetes API 相容性不是問題。
  • 當您用 NodeImage 作為升級通道時，它會遵守您計劃的維護時段，您應至少每週設定一次。 無論您使用什麼節點鏡像作業系統，都應進行設置，以幫助確保及時應用。
  • 這些更新包括作業系統級安全性、相容性和功能更新、作業系統設定設定和 AKS 元件更新。
  • 使用 AKS 版本追蹤器追蹤映像版本及其包含的元件版本號。

如果您的叢集的安全要求需要更積極的修補節奏，並且您的叢集可以容忍潛在的中斷，請改用 SecurityPatch 升級通道。 Microsoft 也測試了這些更新。 只有當 Microsoft 認為安全升級足夠重要，需要在下一次規劃的節點映像升級之前發佈時，才會發布更新。 當您使用該 SecurityPatch 頻道時，您也會獲得 NodeImage 頻道收到的更新。 SecurityPatch 頻道選項仍然尊重您的維護時段，因此請確保您的維護時段有更頻繁的間隙 (例如每天或每隔一天) 以支援這些意外的安全更新。

大多數進行就地升級的叢集應避免使用 None 和 Unmanaged 節點映像升級通道選項。

就地更新集群

Kubernetes 是一個快速發展的平台，定期更新帶來重要的安全修復和新功能。 隨時了解 Kubernetes 更新非常重要。 您應該保持在兩個最新版本或 N-2 範圍內。 由於新版本頻繁發布，因此升級到最新版本的 Kubernetes 至關重要。

大多數叢集應該能夠足夠謹慎和嚴格地執行就地 AKS 版本更新。 透過充分的預生產測試、配額驗證和 Pod 中斷預算設定，可以大幅降低執行就地 AKS 版本升級的風險。 但任何就地升級都可能導致意外行為。 如果認為就地升級對於您的工作負載而言風險太大，我們建議您使用 AKS 叢集方法的藍綠部署，而不是遵循其餘建議。

我們建議您在首次部署 Kubernetes 叢集時避免使用叢集自動升級功能。 使用手動方法，讓你有時間在更新到達生產環境之前在預生產環境中測試新的 AKS 叢集版本。 這種方法還實現了最大程度的可預測性和控制。 但您必須勤於監控 Kubernetes 平台的新更新，並在新版本發佈時迅速採用它們。 最好採取與時俱進的心態，而不是長期的支援方法。

警告

我們不建議自動修補或更新生產 AKS 叢集，即使進行次要版本更新也是如此，除非您先在較低環境中測試這些更新。 有關更多資訊，請參閱定期更新到最新版本的 Kubernetes 和升級 AKS 叢集。

當新的 AKS 版本可用於您的叢集時，您可以使用 Azure 事件網格的 AKS 系統主題接收通知。 參考實作部署此事件網格系統主題，以便您可以從 Microsoft.ContainerService.NewKubernetesVersionAvailable 事件流通知解決方案訂閱事件。 請查看 AKS 發行說明，以了解特定的相容性問題、行為變更或功能棄用。

您最終可能會對 Kubernetes 版本、AKS 版本、叢集、叢集級元件和工作負載充滿信心，以探索自動升級功能。 對於生產系統來說，很難超越 patch。 此外，在自動升級 AKS 版本時，也要檢查叢集的基礎架構即程式碼 (IaC) AKS 版本設置，以免它們不同步。設定計畫的維護時段以支援自動升級操作。

安全性監視

監控您的容器基礎架構是否有主動威脅和潛在安全風險。 以下是一些資源：

叢集和工作負載操作

有關叢集和工作負載操作 (DevOps) 的注意事項，請參閱卓越營運設計原則支柱。

叢集啟動程序

完成設定後，您就擁有了一個工作集群，但在部署工作負載之前可能仍需要執行一些必要的步驟。 準備集群的過程稱為啟動程序。 啟動程序可以包括將必備映像部署到叢集節點、建立命名空間以及執行滿足組織用例要求的其他任務。

為了縮小已設定的叢集與正確設定的叢集之間的差距，叢集操作員應該考慮其獨特的啟動程序過程是什麼樣的。 他們需要提前準備好相關資產。 例如，如果在部署應用程式工作負載之前讓 Kured 在每個節點上執行很重要，則叢集操作員應在設定叢集之前驗證包含目標 Kured 映像的容器登錄執行個體是否已存在。

您可以使用下列方法之一設定啟動程序程序：

注意

這些方法中的任何一種都適用於任何叢集拓撲，但我們建議對佇列使用 GitOps Flux v2 叢集擴展，因為它具有統一性且更容易大規模管理。 當您只執行幾個叢集時，GitOps 可能會過於複雜。 您可能會選擇將該程序整合到一個或多個部署管線中，以確保啟動程序發生。 使用最適合您的組織和團隊目標的方法。

使用 AKS 的 GitOps Flux v2 叢集擴充程式的主要優點之一是，預先設定叢集和引導叢集之間實際上沒有間隙。 它為環境建立了堅實的管理基礎，並且還支援將引導作為資源模板包含在內，以與您的 IaC 原則保持一致。

最後，使用擴充功能時，引導過程的任何部分都不需要 kubectl。 您可以預留基於 kubectl 的存取權限，以應對緊急故障修復情況。 在 Azure 資源定義範本和透過 GitOps 擴充功能開機清單之間，您可以執行所有正常設定活動，而無需使用 kubectl。

隔離工作負載職責

按團隊和資源類型劃分工作負載，以單獨管理每個部分。

從包含基本元件的基本工作負載開始，並在此基礎上進行建置。 初始任務是設定網路。 為中心和分支以及這些網路內的子網路設定虛擬網路。 例如，分支具有用於系統和使用者節點集區以及入口資源的單獨子網路。 在中樞部署 Azure 防火牆的子網路。

另一項任務是將基本工作負載與 Microsoft Entra ID 整合。

使用 IaC

盡可能選擇冪等宣告式方法而不是命令式方法。 不要編寫指定設定選項的命令序列，而是使用描述資源及其屬性的聲明性語法。 您可以使用 Bicep、Azure 資源管理器範本 (ARM 範本) 或 Terraform。

請務必根據管理政策設定資源。 例如，當您選擇 VM 大小時，請遵守成本限制和可用性區域選項，以滿足應用程式的要求。 你也可以使用 Azure Policy 來強制執行組織針對這些決策的原則。

如果需要編寫一系列命令，請使用 Azure CLI。 這些命令涵蓋一系列 Azure 服務，您可以透過腳本自動化它們。 Windows 和 Linux 支援 Azure CLI。 另一個跨平台選項是 Azure PowerShell。 您的選擇取決於您的首選技能。

在原始碼管理系統中儲存腳本和模板檔案並對其進行版本控制。

工作負載 CI/CD

工作流程和部署管線必須能夠持續建置和部署應用程式。 更新必須安全、快速地部署，並在出現問題時回滾。

您的部署原則需要包括可靠且自動化的持續交付管線。 自動將工作負載容器映像中的變更部署到叢集。

在此架構中，GitHub Actions 管理工作流程和部署。 其他流行的選項包括 Azure DevOps 和 Jenkins。

叢集 CI/CD

顯示工作負載 CI/CD 的圖表。

下載此架構的 Visio 檔案。

不要使用像 kubectl 這樣的命令式方法，而是使用自動同步叢集和儲存庫變更的工具。 若要管理工作流程，例如新版本的發布以及部署到生產之前對該版本的驗證，請考慮使用 GitOps 流程。

CI/CD 流程的一個重要部分是引導新設定的叢集。 GitOps 方法很有用，因為它允許操作員以聲明方式將引導過程定義為 IaC 原則的一部分，並自動查看叢集中反映的設定。

當您使用 GitOps 時，會在叢集中部署一個代理，以確保叢集的狀態與儲存在您的私有 Git 儲存庫中的設定相協調。 Flux 就是這樣的代理，它使用叢集中的一個或多個操作符來觸發 Kubernetes 內的部署。 Flux 執行下列任務：

  • 監視所有設定的儲存庫。
  • 檢測新的設定變更。
  • 觸發部署。
  • 根據這些變更更新所需的運作設定。

您也可以設定原則來管理如何部署變更。

以下範例展示如何使用 GitOps 和 Flux 自動進行叢集設定：

顯示 GitOps 流程的圖表。

下載此架構的 Visio 檔案。

  1. 開發人員提交對原始程式碼的更改，例如儲存在 Git 儲存庫中的設定 YAML 檔案。 然後將變更推送到 Git 伺服器。

  2. Flux 與工作負載一起在 Pod 中運作。 Flux 對 Git 儲存庫具有唯讀存取權限，以確保 Flux 僅根據開發人員的請求套用變更。

  3. Flux 識別設定中的變更並使用 kubectl 命令套用這些變更。

  4. 開發人員無法透過 kubectl 直接存取 Kubernetes API。

您可以在 Git 伺服器上設定分支原則，以便多個開發人員可以在將變更套用至生產之前透過拉取請求來批准變更。

雖然您可以手動設定 GitOps 和 Flux，但我們建議為 AKS 使用具有 Flux v2 叢集擴充功能的 GitOps。

工作負載和叢集部署原則

將任何變更 (例如架構元件、工作負載和叢集設定) 部署到至少一個預生產 AKS 叢集。 這樣做可以模擬更改，並可能在將問題部署到生產之前識別問題。

在進入下一階段之前，在每個階段執行測試和驗證。 它有助於確保您能夠以高度受控的方式將更新推送到生產環境，並最大限度地減少意外部署問題造成的中斷。 部署應遵循與生產類似的模式，使用相同的 GitHub Actions 管線或 Flux 運算子。

進階部署技術，例如藍綠部署、A/B 測試和金絲雀發布，需要額外的流程和潛在的額外工具。 Flagger 是一種流行的開源解決方案，可協助解決進階部署場景。

成本管理

首先查看 AKS 架構完善的框架中概述的成本優化設計清單和建議清單。 使用 Azure 定價計算器來估算體系架構中所使用的服務的成本。 有關其他最佳做法，請參閱成本最佳化。

考慮使用 AKS 成本分析，透過 Kubernetes 特定的構造進行精細叢集基礎設施成本分配。

有關 Windows 的成本管理注意事項的資訊，請參閱 AKS 上的 Windows 容器。

佈建

  • 了解您的成本從何而來。 在 Kubernetes 叢集本身的部署、管理和操作方面，與 AKS 相關的成本極低。 影響成本的是叢集消耗的虛擬機器執行個體、儲存、記錄資料和網路資源。 考慮為系統節點集區選擇更便宜的虛擬機器。 DS2_v2 系列是系統節點集區的典型虛擬機器類型。

  • 開發/測試和生產環境沒有相同的設定。 生產工作負載對高可用性有額外的要求，通常更昂貴。 在開發/測試環境中不需要此設定。

  • 為生產工作負載新增正常運作時間 SLA。 但是，為不需要保證可用性的開發/測試或實驗工作負載而設計的叢集可以節省成本。 例如，SLO 就足夠了。 此外，如果您的工作負載支持，請考慮使用執行點虛擬機器的現成節點集區。

    對於包含 Azure SQL 資料庫或 Azure 應用程式服務作為 AKS 工作負載體系結構一部分的非生產工作負載，請評估您是否有資格使用 Azure 開發/測試訂閱來接收服務折扣。

  • 設定具有最少節點數的集群，並使集群自動縮放程式能夠監視並做出調整大小決策，而不是從超大集群開始以滿足擴展需求。

  • 設定 pod 請求和限制，讓 Kubernetes 以更高密度分配節點資源，以便您充分利用硬體。

  • 請注意，當您在叢集上啟用診斷時，可能會增加成本。

  • 如果您的工作負載必須長期存在，承諾一年或三年的 Azure 預留虛擬機器執行個體可降低節點成本。 有關詳細資訊，請參閱使用 Azure 預留虛擬機器執行個體節省成本。

  • 建立節點集區時使用標籤。 標籤可協助您建立自訂報告來追蹤所產生的成本。 您可以使用標籤來追蹤總費用並將任何成本對應到特定資源或團隊。 此外，如果叢集在團隊之間共享，請為每個消費者建立退款報告，以確定共享雲端服務的計量成本。 有關詳細資訊，請參閱指定節點集區的污點、標籤或標記。

  • 如果您的工作負載是多區域的並且您在區域之間複製資料，則預計會產生額外的頻寬成本。 有關詳細資訊，請參閱頻寬定價。

  • 建立預算以保持在您的組織確定的成本限制範圍內。 您可以透過 Microsoft 成本管理建立預算。 您還可以建立警報，以便在超過特定閾值時收到通知。 關於詳細資訊，請參閱使用範本建立預算。

監視器

您可以監控整個叢集以及運算、儲存、頻寬、記錄和防火牆的成本。 Azure 提供了監控和分析成本的選項：

理想情況下，即時或至少定期監控您的成本。 然後，您可以在已計算成本的月底之前採取行動。 此外，也要監控一段時間內的每月趨勢，以保持在預算之內。

要做出資料驅動的決策，請在粒度層級上找出哪些資源產生的成本最高。 此外，也要充分了解計算資源使用情況的儀表。 例如，透過分析指標，可以判斷平台是否規模過大。 您可以在 Azure 監視器指標中查看使用量計量。

最佳化

根據 Azure Advisor 提供的建議採取行動。 還有其他最佳化方式：

  • 啟用叢集自動縮放程式以偵測並刪除節點集區中未充分使用的節點。

    重要

    積極更改叢集自動縮放程式設定 (例如節點集區的最小和最大節點設定) 以影響成本可能會產生適得其反的結果。 例如，如果 scale-down-unneeded-time 設定為10分鐘，並且根據工作負載特徵每五分鐘修改一次最小和最大節點設置，則節點數量永遠不會減少。 這是因為由於刷新叢集自動縮放程序設置，每個節點的不需要時間的計算都會重置。

  • 如果您的工作負載支持，請為節點集區選擇較低的 SKU。

  • 如果應用程式不需要突發擴展，請考慮透過分析一段時間內的效能指標來將叢集調整為適當的大小。

  • 如果您的工作負載支持，請在不需要使用者節點集區執行時將其擴展到 0 個節點。 此外，如果叢集中沒有計劃執行的工作負載，請考慮使用 AKS 啟動/停止功能關閉所有運算，其中包括系統節點集區和 AKS 控制平面。

有關其他成本相關資訊，請參閱 AKS 定價。

下一步