共用方式為

Azure Kubernetes 服務（AKS）叢集的基準架構

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

本文提供一個推薦的基線基礎架構，以部署 Azure Kubernetes Service（AKS）叢集。 它遵循我們的設計原則，並與 Azure Well-Architected 框架 中的 AKS 架構最佳實務保持一致。 本文指導多個不同的跨領域團隊，例如網路、安全和身份識別團隊，如何部署這一通用型基礎架構。

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

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

Kubernetes 是一個廣泛的生態系統，超越了 Azure 和 Microsoft 技術。 當你部署 AKS 叢集時，你必須負責許多關於如何設計和運作叢集的決策。 運行 AKS 叢集涉及來自多家廠商的閉源元件，包括 Microsoft，以及來自 Kubernetes 生態系統的開源元件。 環境經常變化，因此請定期檢視決策。 當你採用 Kubernetes 時，你承認你的工作負載需要其能力，且你的工作負載團隊已準備好持續投資。

你可以使用 GitHub：AKS baseline reference implementation 作為起始選項，並根據您的需求進行配置。

Note

參考架構需要了解 Kubernetes 及其概念。 如果你需要複習，可以參考 Kubernetes 入門 以及 在 Kubernetes 上開發和部署應用程式 的訓練路徑。

網路設定

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

叢集計算

基礎叢集的計算
容器映像引用
政策管理

身分識別管理

整合 Microsoft Entra ID 以用於叢集
整合 Microsoft Entra ID 至工作負載

安全數據流程

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

商務持續性

節點與莢艙的可擴展性
業務持續性決策
可用區域多區域

Operations

叢集與工作負載操作
監控並收集日誌與指標
成本管理

Architecture

架構圖，顯示樞紐輻射式網路拓撲。

下載此架構的Visio檔案.

更多資訊請參閱Azure 中的樞輻式網路拓撲。

網路拓撲

此架構採用樞紐輻射式網路拓撲。 將樞紐與輻射部署在獨立的虛擬網路中，這些網路透過虛擬網路對等連接起來。 此拓撲有幾個優點：

  • 啟用隔離管理。 你可以應用治理並遵守最小特權原則（PoLP）。 同時也支持Azure著陸區的概念，並實現職責分離。

  • 盡量減少 Azure 資源直接暴露於公共網際網路。

  • 提供區域樞紐輻射拓撲。 未來你可以擴展樞紐輻射式網路拓撲，並提供工作負載隔離。

  • 使用web application firewall服務來協助檢查所有網頁應用程式的HTTP流量。

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

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

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

  • 對齊Azure企業級著陸區。

Hub virtual network

樞紐虛擬網路（hub virtual network）是連接與可觀察的核心點。 在此架構中，樞紐包含以下元件：

  • Azure Firewall 搭配全球防火牆政策，由您的中央 IT 團隊定義以執行全組織規則

  • Azure Bastion，它會建立一條安全隧道進入私有網路邊界，讓你能執行叢集管理操作

  • VPN 連接的閘道子網

  • Azure Monitor 用於網路可觀測性

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

主機 Azure 防火牆的子網路

Azure Firewall 是一個受管理的防火牆服務。 Azure Firewall 實例負責保護外出網路流量。 如果沒有這一層安全性，流量可能會與惡意的非 Microsoft 服務進行通信，從而洩露敏感的工作負載資料。 使用 Azure Firewall Manager集中部署與配置多個 Azure Firewall 實例，並管理此 hub virtual network<> 架構類型的Azure Firewall政策。

適合承載閘道的子網路

這個子網是 VPN gateway 或 Azure ExpressRoute 閘道的佔位符。 閘道器提供本地網路中路由器與 virtual network 之間的連接。

子網路以承載 Azure Bastion

此子網用於 Azure Bastion。 你可以使用 Azure Bastion 以安全的方式存取 Azure 資源，且不將資源暴露在網際網路上。 此架構使用 Azure Bastion 安全連接 AKS 叢集的 API 伺服器以進行管理操作。 子網路僅供管理和營運使用。

發言虛擬網路

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

子網路以托管 Azure 應用程式閘道

Azure Application Gateway 是一個運作於第 7 層的網頁流量負載平衡器。 參考實作使用 Application Gateway v2 SKU，該 SKU 啟用 Azure Web Application Firewall。 Web Application Firewall 保護進來流量免受常見的網路流量攻擊，包括機器人攻擊。 此執行個體具有接收使用者請求的公共前端 IP 設定。 設計上，Application Gateway 需要專用子網路。

要承載入口資源的子網路

為了路由和散發流量， Traefik 是滿足 Kubernetes 輸入資源的輸入控制器。 Azure 內部負載平衡器存在於此子網中。 更多資訊請參見在 AKS 中使用內部負載平衡器。

用於承載叢集節點的子網路

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

建立適用於 Azure Container Registry 和 Azure Key Vault 的 Azure Private Link 連線，以便使用者可以透過輔助虛擬網路中的 私人端點 使用這些服務。 專用端點不需要專用子網路。 你也可以把私有端點放在 Hub virtual network 裡。 在基線實作中，端點被部署到輻射型虛擬網路內的專用子網路。 此方法可減少經由對等網路連線傳輸的流量。 它會將屬於叢集的資源保持在同一個 virtual network 中。 你也可以在子網層級使用網路安全群組（NSG）來套用細緻的安全規則。

欲了解更多資訊，請參閱 Private Link 部署選項。

AKS API 伺服器的子網路

你可以配置 AKS 叢集使用 API 伺服器虛擬網路整合，將叢集的 API 伺服器端點投影到您的虛擬網路中的委派子網。 這種配置稱為 私有叢集 ，因為它確保 API 伺服器、節點池與連接用戶端之間的所有流量都完全停留在你的私人網路內。

AKS 管理的 Kubernetes API 伺服器與用戶端（包括叢集內部及外部用戶端）之間的所有通訊都限制在受信任的網路中。

有了私有叢集，你可以利用 NSG 和其他內建的網路控制來保護你的環境。 此配置禁止網際網路與環境之間任何未經授權的公共訪問。 更多資訊請參見 Create a private AKS cluster。

規劃 IP 位址

顯示 AKS 叢集網路拓撲的圖解。

下載此架構的Visio檔案.

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

  • 你用來管理資源的Azure virtual network，例如叢集節點、叢集的 API 伺服器、Azure服務的私有端點，以及 Application Gateway。

  • 叢集使用 Azure 容器網路介面（CNI）疊加網路，將 IP 位址從 Azure 虛擬網路的獨立位址空間分配給 Pod。

虛擬網路 IP 位址空間

你的Azure virtual network的位址空間應該足夠大，能容納所有子網。 記錄接收流量的所有實體。 Kubernetes 會從子網位址空間分配實體的 IP 位址。 規劃Azure virtual network IP位址時，請考慮以下幾點：

  • 升級： AKS 定期更新節點，確保底層虛擬機的安全功能及系統修補程式保持最新。 在升級過程中，AKS 會建立一個節點來暫時承載 Pod，升級中的節點則會被隔離和清空。 該臨時節點會從叢集子網路接收一個 IP 位址。 確保你有足夠的位址空間來存放臨時節點的 IP 位址。

    在此架構中，Pod 的 IP 位址會從 Azure CNI Overlay Pod 位址空間中分配，包括在進行滾動更新期間也是如此。 此方法能減少 Azure 虛擬網路中使用的 IP 位址總數，相較於其他 Kubernetes 網路方案。

  • 可擴展性： 考慮系統與使用者節點的總數及其最大擴展性限制。 例如，如果你想擴展至400%，則需要將所有擴展後節點的地址數量增加到四倍。

    由於此架構使用 Azure CNI Overlay，您的 Pod 可擴展性不會影響 virtual network 的位址空間。

  • Private Link 位址： 考慮與其他Azure服務在 Private Link 上通訊所需的位址。 此架構為容器登錄檔與 Key Vault 連結分配了兩個位址。

  • Private cluster API server addresses： API 伺服器虛擬網路整合可協助您將 AKS API 伺服器呈現在虛擬網路內的端點。 此功能要求最小子網大小，因此在網路規劃時務必符合這些先決條件。

  • 保留IP位址： Azure保留特定位址用於其用途。 他們不能被分配。

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

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

Pod IP 位址空間

Azure CNI Overlay 會透過一個專用位址空間分配 IP 位址給 pods，這個空間和你在 virtual network 中使用的位址空間是分開的。 使用不與你的虛擬網路或任何對等虛擬網路重疊的 IP 位址空間。 但如果你建立多個 AKS 叢集，就可以安全地在每個叢集使用相同的 pod 位址空間。

Azure CNI Overlay 會為每個節點分配一個 /24 位址空間給其的 Pod。 確保莢艙位址空間足夠大非常重要。 根據叢集節點數量，允許配置所需的 /24 區塊。 請記住包括在升級或橫向擴展操作期間生成的任何臨時節點。 舉例來說，如果你用 /16 位址空間作為無類別域間路由（CIDR）範圍，叢集最多可擴充到約 250 個節點。

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

欲了解更多資訊，請參閱 關於 Azure CNI 覆蓋層 IP 位址規劃的指引。

其他 IP 位址空間注意事項

關於此架構的完整網路考量，請參見 AKS 基線網路拓撲。 欲了解更多如何規劃 AKS 叢集的 IP 位址，請參見 在 AKS 配置 Azure CNI 網路。

附加元件和預覽功能

Kubernetes 與 AKS 持續演進，發布週期比本地環境軟體更快。 此基礎架構依賴特定的 AKS 預覽功能與 AKS 附加元件。 請考慮預覽功能與附加元件之間的以下差異：

  • AKS 團隊將預覽功能描述為已發布並在持續改進中，因為許多預覽功能僅維持數月後便進入正式可用性（GA）階段。

  • AKS 附加元件與擴充功能提供額外且支援的功能。 AKS 負責管理其安裝、配置及生命週期。

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

容器映像引用

叢集可能包含工作負載以及其他一些映像檔，像是入口控制器。 其中一些影像可能駐留在公共登錄中。 當你將影像拉入你的群組時，請考慮以下幾點：

  • 為叢集進行認證以提取映像檔。

  • 如果你使用公開映像檔，請將映像檔匯入與你的服務層目標（SLO）對齊的容器登錄檔。 否則，映像可能會出現意外的可用性問題。 如果在需要時無法取得映像檔，可能會產生操作問題。 請考慮使用私人容器登錄檔（如 Azure Container Registry）而非公開登錄檔的以下優點：

    • 你可以阻擋未經授權的存取圖像。
    • 您沒有面向公眾的依賴項。
    • 你可以存取映像拉取紀錄來監控活動並排查連線問題。
    • 您可以利用整合的容器掃描和映像檔合規性。

  • 從授權登錄中提取影像。 你可以透過 Azure Policy 強制執行此限制。 在此參考實作中，叢集只會從與叢集一同部署的專用 Azure Container Registry 實例拉取映像檔。

設定基底叢集的計算

在 AKS 中，每個節點集區通常會對應至虛擬機器規模集。 節點是每個節點池中的虛擬機器 (VMs)。

請考慮針對系統節點集區使用較小的 VM 大小，以將成本降到最低。 此參考實作會部署具有三個 D2dv5 節點的系統節點集區。 該容量足以應付系統 Pod 的預期負載。 作業系統的臨時磁碟容量為 64 GB。

在規劃使用者節點池容量時，請考慮以下建議：

  • 選擇較大的節點大小，以封裝節點上設定的 Pod 數目上限。 大型節點能減少所有節點上運行的服務規模，例如監控與日誌記錄。

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

  • 至少部署兩個節點，讓工作負載能遵循高可用性模式，並使用兩個副本。 使用 AKS，您可以變更節點數，而不需要重新建立叢集。

  • 根據設計團隊所決定的需求，規劃實際節點大小以符合你的工作負載。 根據商務需求，此架構會針對生產工作負載使用 D4dv5 SKU。

  • 當你在規劃叢集容量時，假設每個節點的工作負載最多佔用 80%。 剩餘的 20% 保留用於 AKS 服務。

  • 根據你的容量規劃，為每個節點設定最大儲存艙數量。 如果你嘗試建立容量基準，建議從30開始。 根據工作負載需求、節點大小和 IP 位址限制來調整這個數值。

選取作業系統

大多數 AKS 叢集使用 Linux 作為其節點集區的作業系統。 在這個參考實作中，我們使用 Azure Linux，這是一個輕量級、強化的 Linux 發行版，針對Azure進行調校。 如果你偏好，或是 Azure Linux 不符合需求，也可以選擇其他 Linux 發行版，例如 Ubuntu。 如果你選擇了不同的作業系統，請確保作業系統磁碟的大小與該映像檔相符。 有些發行版比 Azure Linux 需要更多空間，所以你可能需要增加磁碟大小以避免部署或執行時的問題。

如果你的工作負載是混合技術，你可以在不同的節點池中使用不同的作業系統。 但如果您不需要不同的作業系統，我們建議您為所有工作負載節點池使用單一作業系統，以降低營運複雜度。

整合 Microsoft Entra ID 用於叢集

確保叢集的進出安全至關重要。 利用叢集的觀點來理解內向外流量與外向內流量的差異：

  • Inside-out access： 考慮 AKS 存取 Azure 的元件，例如網路基礎設施、容器映像檔庫和 Key Vault 等。 只授權叢集被允許存取的資源。

  • Outside-in access： 提供身份對 Kubernetes 叢集的存取權限。 只授權那些被允許訪問 Kubernetes API 伺服器和 Azure Resource Manager 的外部實體。

AKS 存取 Azure 元件

透過 Microsoft Entra ID，有兩種方式來管理對 Azure 的 AKS 存取：service principals 或用於 Azure 資源的 managed identities。

在管理 AKS 存取 Azure 的兩種方法中，我們推薦使用受管理的識別。 對於服務主體，您必須手動或以程式方式管理和輪調密碼。 透過管理身份，Microsoft Entra ID 會為您管理並執行秘密的認證與及時輪替。

我們建議您在 AKS 啟用並使用 managed identities，讓叢集能透過 Microsoft Entra ID 與外部Azure資源互動。 如果你沒有立即使用 Microsoft Entra ID 整合，可以之後再加。

預設情況下，叢集使用兩個主要身份： 叢集身份 與 kubelet 身份。 AKS 控制平面元件使用 叢集身份 來管理叢集資源，包括入口負載平衡器，以及 AKS 管理的公有 IP 位址。 kubelet 身分識別會向 Container Registry 進行驗證。 某些附加元件還支援使用託管身份進行身份驗證。

當叢集需要從容器登錄中提取映像時，您應該使用託管身分。 此操作需要叢集取得註冊表憑證，您可以透過將 AcrPull 核准給叢集的 kubelet 管理的身份來存取您的註冊表。 如果你沒有使用管理身份，你可以把這些資訊存到 Kubernetes 的秘密裡，然後用 imagePullSecrets 來取回。 我們不建議採用這種做法，因為它會帶來安全複雜性，包括必須事先知道機密並將其儲存在 DevOps 流程中。 這也增加了營運負擔，因為您必須輪換密鑰。

在此架構中，叢集存取 Microsoft Entra ID 所保護的 Azure 資源，叢集執行支援受管理身份的操作。 根據叢集執行的操作，為叢集的受控身份分配Azure角色型存取控制和許可權。 叢集會向 Microsoft Entra ID 自我驗證，然後根據分配給它的角色來允許或拒絕存取。 以下是本參考實作中將 Azure 內建角色分配給叢集的一些範例：

  • 網路貢獻者角色管理叢集控制相關虛擬網路的能力。 透過此角色分配，AKS 叢集系統指派的身份可與內部入口控制器服務的專用子網及 AKS 私有 API 伺服器合作。

  • Private DNS區域貢獻者角色管理叢集將該區域直接連結至承載叢集的輻射虛擬網路的能力。 私有叢集透過使用private DNS區域，將 DNS 紀錄從公共網際網路中移除。 但仍然可以建立一個擁有公共 DNS 位址的私有 AKS 叢集。 我們 建議您明確 禁止此功能，設定 enablePrivateClusterPublicFQDN 為 false 禁止洩漏控制平面的私人 IP 位址。 考慮使用 Azure Policy 強制使用沒有公開 DNS 記錄的私有叢集。

  • 監控指標發佈器角色管理叢集將指標傳送到 Azure 監控的能力。

  • AcrPull 角色管理叢集從指定的容器登錄實例拉取映像的能力。

叢集存取

Microsoft Entra 的整合也簡化了外來訪問的安全性。 例如，您可能想要使用 kubectl。 作為初始步驟，您可以執行az aks get-credentials命令來取得叢集的憑證。 Microsoft Entra ID 會用 Azure 角色驗證你的身份，這些角色被允許取得叢集憑證。 欲了解更多資訊，請參閱 可用叢集角色權限。

AKS 支援透過 Microsoft Entra ID 存取 Kubernetes，方式包括使用 Microsoft Entra ID 作為身分識別提供者並整合原生 Kubernetes RBAC，或利用原生 Azure RBAC 來控制叢集存取。 以下部分詳細介紹兩種方法。

將 Kubernetes RBAC 與 Microsoft Entra ID 關聯

Kubernetes 透過以下 API 物件支援 RBAC：

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

  • 綁定指派有權限執行動作的使用者和群組。 使用 RoleBinding 或 ClusterRoleBinding 物件定義綁定。

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

請務必在你的 Microsoft Entra 存取审查 中包含 Microsoft Entra 群組的叢集與命名空間存取。

使用 Azure RBAC 進行 Kubernetes 授權

我們建議您使用 Azure RBAC 和 Azure 角色指派來強制叢集進行授權檢查。 此授權方法與 Microsoft Entra 驗證整合。 你可以在不同範圍內指派角色，例如管理群組、訂閱或資源群組。 範圍內的所有叢集都會繼承一套一致的角色指派，確定哪些人具備權限，能夠在 Kubernetes 叢集上存取物件。

我們不建議使用 Kubernetes 原生的 RBAC 系統與 ClusterRoleBindings 和 RoleBindings 搭配使用。

欲了解更多資訊，請參閱 Azure RBAC for Kubernetes 授權。

本機帳戶

AKS 支援原生的 Kubernetes 使用者驗證。 我們不建議你使用這種方法來給予使用者存取叢集。 此方法基於憑證，並由外部對主要身份提供者執行，這使集中式使用者訪問控制和治理變得困難。 一定要用 Microsoft Entra ID 來管理叢集access，並設定叢集明確禁止本地帳號access。

在此參考實作中，系統部署叢集時明確禁止access本地叢集帳號。

整合 Microsoft Entra ID 來處理工作負載

就像整個叢集由 Azure 系統指派的管理身份一樣，你可以在 Pod 層級指派受管理身份。 工作負載身份讓託管工作負載能透過Microsoft Entra ID來access資源。 舉例來說，假設工作負載將檔案存放在 Azure Storage。 當 Pod 需要 access 這些檔案時，會以 Azure 管理身份對資源進行認證。

在此參考實作中，Microsoft Entra Workload ID 在 AKS 上提供 pod 的管理身份。 此方法與 Kubernetes 的原生功能整合，進而與外部身分識別提供者結合。 如需詳細資訊，請參閱 工作負載身分識別聯邦。

選擇網路模型

Important

在 2028 年 3 月 31 日，Azure Kubernetes Service (AKS) 的 kubenet 網路將被停用。

為避免服務中斷，您需要在日期之前升級至 Azure 容器網路介面（CNI）覆蓋網，屆時 AKS 上使用 kubenet 執行的負載將不再支援。

AKS 支援多種網路模型，包括 kubenet、CNI 及 Azure CNI 覆蓋層。 CNI 型號則是較先進的型號，提供高性能。 當它們在 pod 間通訊時，CNI 的效能與虛擬機在 virtual network 中的效能相當。 CNI 也提供更強的安全控管，因為它允許使用 Azure 網路政策。 我們推薦基於 CNI 的網路模型。

在非覆蓋 CNI 模型中，每個 pod 會從子網位址空間獲得一個 IP 位址。 同一網路內的資源（或對等資源）可以直接透過 IP 位址存取 Pod。 網路位址轉換（NAT）並非必須來路由這些流量。

在這個參考實作中，我們使用 Azure CNI Overlay。 它只從節點池子網分配 IP 位址給節點，並對 Pod IP 使用優化的覆蓋層。 由於 Azure CNI Overlay 使用的虛擬網路 IP 位址比許多其他方法少，我們建議用於 IP 位址資源有限的部署。

欲了解更多模型資訊，請參閱 Configure Azure CNI Overlay Networking in AKS 及 AKS 網路連接與安全的最佳實務。

部署輸入資源

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

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

    此架構使用 Azure Load Balancer。 Load Balancer 位於叢集外的子網路，專門用於輸入資源。 它接收來自 Application Gateway 的流量，且該通訊是透過傳輸層安全（TLS）進行的。 欲了解更多關於進站流量 TLS 加密的資訊，請參閱 入口流量 章節。

  • 入口控制器： 這個例子使用 Traefik。 它執行在叢集中的使用者節點集區中。 它接收來自內部負載平衡器的流量，終止 TLS 連線，並透過 HTTP 將其轉發至工作負載 Pod。

入口控制器是叢集的關鍵元件。 在配置此元件時，請考慮以下幾點。

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

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

  • 使用 nodeSelectors 限制 pod 只能在用戶節點池上進行調度。 此設定可隔離工作負載和系統 Pod。

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

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

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

Note

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

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

你也可以使用 Application Gateway Ingress Controller，這和 AKS 整合得很好。 Application Gateway 除了作為入口控制器的角色外，還帶來更多好處。 它作為叢集的virtual network入口點，可以觀察進入叢集的流量。 如果你的應用程式需要 web application firewall，請使用 Application Gateway。 同時也支援 TLS 終止。

路由器設定

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

以下是該架構的範例：

Traefik 使用 Kubernetes 提供者來設定路由。 annotations、 tls 和 entrypoints 選項指示透過 HTTPS 提供路由。 middlewares 選項指定只允許來自Application Gateway子網的流量。 如果客戶端接受，回應將使用 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 之間的流量 。 此流量包括輸入控制器與工作負載之間的通訊。 如果您的工作負載由部署到叢集的多個應用程式組成，那麼這些應用程式之間的通訊也屬於此類。

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

顯示叢集流量的圖表。

下載此架構的Visio檔案.

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

進入流量

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

顯示TLS終端的圖解。

下載此架構的Visio檔案.

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

  2. Application Gateway 有整合的網站應用程式防火牆，並與 bicycle.contoso.com 的 TLS 握手協商，只允許安全加密算法。 Application Gateway 是 TLS 終端點，這很重要，因為 Application Gateway 的 web application firewall 需要檢查明文請求與回應。 Key Vault 會儲存 TLS 憑證。 叢集以使用者指派的管理身份存取，該身份與 Application Gateway 整合。 欲了解更多資訊，請參閱TLS終止與Key Vault憑證。

    Application Gateway 處理 web application firewall 檢查規則，並執行路由規則將流量轉發至已設定的後端。

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

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

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

出口流量

在此架構中，我們建議叢集的所有出口流量都必須經過 Azure Firewall。 你也可以使用自己類似的網路虛擬設備。 我們不建議使用其他出口選項，例如 Azure NAT Gateway或 HTTP 代理，因為它們不提供網路流量檢查。 為了 Zero Trust 控制和流量檢查，所有出口流量都透過 Azure Firewall 傳送。 請使用使用者自訂路由（UDR）實作此配置。 路由的下一跳是 Azure Firewall 的私有 IP 位址。 Azure Firewall 會根據你定義的規則或內建的威脅情報規則，決定是阻擋還是允許出口流量。

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

無論哪種方法，請檢視 AKS 所需的 出口網路流量規則。

Note

如果你使用公用負載平衡器作為 Azure 防火牆透過 UDR 進行流量進出口的公共端點，你可能會看到 非對稱路由情境。 此架構使用內部負載平衡器，設置於 Application Gateway 後方的專用入口子網路中。 此設計提升安全性，並消除非對稱路由問題。 或者你可以在 Application Gateway 之前或之後將流量路由 Firewall，但這種方法在大多數情況下並非必要，我們也不建議這麼做。 欲了解更多非對稱路由資訊，請參閱 將防火牆與 Azure 標準負載平衡器整合。

Zero Trust 控制的例外是叢集需要與其他 Azure 資源通訊。 例如，叢集可能需要從容器登錄檔拉取更新的映像檔，或從 Key Vault 抓取秘密資料。 在這些情況下，我們建議使用 Private Link。

使用 Private Link 的優點是特定子網會直接連接到服務，叢集與服務之間的流量不會經過網際網路。 缺點是 Private Link 需要額外設定，而不是透過其公共端點使用目標服務。 另外，並非所有 Azure 服務或產品都支援 Private Link。 在這種情況下，可以考慮在子網路上啟用虛擬網路服務端點來訪問服務。

如果無法使用 Private Link 或服務端點選項，您可以通過其他服務的公用端點進行連接，並通過 Azure Firewall 規則與目標服務內建的防火牆來控制存取。 因為這些流量會經過防火牆的靜態 IP 位址，你可以把這些位址加入服務的 IP 允許清單。

透過公開端點連接 Azure 服務的一個缺點是，Azure Firewall 需要更多規則來確保只能允許來自特定子網的流量。 在計劃使用多個 IP 位址進行 Azure Firewall 的出口流量時，請考慮這些位址。 否則，您可能會遇到連接埠耗盡的情況。 關於如何規劃多個 IP 位址的更多資訊，請參見 建立擁有多個 IP 位址的Azure Firewall。

Pod 對 Pod 流量

預設情況下，Pod 可以接受來自叢集中任何其他 Pod 的流量。 使用 Kubernetes NetworkPolicy 限制 Pod 之間的網路流量。 請謹慎執行政策，否則可能會遇到關鍵網路流被阻擋的情況。 僅 根據需求允許特定的通訊路徑，例如入口控制器與工作負載之間的流量。 欲了解更多資訊，請參閱 Network 政策。

在設置叢集時啟用網路政策，因為之後無法新增。 您可以選擇多種技術來實現 NetworkPolicy。 我們建議使用 Azure 網路規則，並且需要 Azure CNI。 其他選項包括 Calico 網路原則，這是一個著名的開源選項。 如果您需要管理叢集範圍的網路原則，請考慮 Calico。 Calico 不在標準 Azure support 裡。

欲了解更多資訊，請參閱 Azure網路政策引擎的差異。

管理網絡流量

作為叢集運行的一部分，Kubernetes API 伺服器會接收來自需要進行管理操作的資源的流量，例如請求建立資源以擴展叢集。 這些資源的例子包括 DevOps 管線中的建置代理池、Azure Bastion 子網內的 Azure Bastion 實例，以及節點池本身。 我們建議你不要接受所有 IP 位址的管理流量，而是建立一個私有 AKS 叢集。

欲了解更多資訊，請參閱 定義 API 伺服器授權 IP 範圍。

我們建議您將 AKS 叢集部署為私有叢集。 所有控制平面和節點池的流量都留在你的私人網路上，不會暴露在公共網路上。 此參考實作透過 API 伺服器與 virtual network 整合建立私有叢集。 較低階的環境可能會考慮放寬對私有叢集的建議，以提升便利性。 但生產環境的 AKS 叢集應該始終部署為私有叢集，以確保部署基線安全。

私有 AKS 叢集的私有流量可能來自輻射臂虛擬網路、對等連接的網路，或遠端網路中的私有端點。 雖然 AKS 節點自然存在於分支，但執行行政任務的管理員需要專用網路路徑，才能以私密方式連接到 AKS API 伺服器。 你可以透過以下方式建立這種連結：

  • Tunnelling： 使用 Azure Bastion 直接開啟一條隧道通往叢集的 API 伺服器。
  • 跳接盒： 配置跳接盒虛擬機，並利用 Azure Bastion 透過 SSH 或 RDP 連接。 接著，營運者會透過叢集的私有 IP 位址對叢集的 API 伺服器提出請求。

在參考實作中，我們使用 Azure Bastion 進行叢集管理操作時，透過隧道連接至 AKS API 伺服器。 一般而言，此方法管理更簡單，成本低於部署與管理跳接盒虛擬機，且多位操作員間協調時也較不複雜。 不過，如果你有以下任何一項需求，也可以選擇使用跳線盒虛擬機：

  • 操作員使用不安全的裝置。 如果客戶端裝置不被信任，跳板虛擬機可以提供更強的安全強化。
  • 業者透過不穩定的網路連線。 跳板虛擬機能提供穩定的叢集連線，尤其是在長時間執行或批次管理作業時。
  • 操作員使用先進的診斷工具。 某些診斷工具，如封包擷取，可能不太適合隧道技術。

新增秘密管理

將秘密存放在管理型金鑰庫，例如 Key Vault。 優點在於受管理的金鑰存儲可以處理密鑰旋轉。 它提供強加密及 access 稽核日誌。 它還將關鍵秘密保留在部署流程之外。 在此架構中，會啟用並設定 Key Vault 防火牆，並使用私人連結來連接 Azure 資源，例如讓 Key Vault 存取秘密和憑證。

Key Vault 與其他 Azure 服務整合良好。 利用這些服務內建的功能來存取秘密。 欲了解更多關於 Application Gateway 如何存取 TLS 憑證以取得入口流的資訊，請參閱 入口流量章節。

Key Vault 的 Azure RBAC 權限模型允許您將工作負載身份指派給 Key Vault Secrets 使用者或 Key Vault 讀取器角色，並access這些秘密。 欲了解更多資訊，請參考Access Key Vault，使用Azure RBAC。

存取叢集憑證

你必須使用工作負載身份，才能讓 pod 從特定儲存庫存取秘密。 為了方便檢索過程，請使用 secrets store 的 CSI 驅動程式。 當 Pod 需要機密時，驅動程式會與指定的儲存連接，檢索磁碟區上的機密，並將該磁碟區掛載到叢集中。 然後 Pod 可以從磁碟區檔案系統取得機密資訊。

CSI 驅動程式有許多供應商支援各種託管儲存。 此實作使用 Key Vault 搭配 secrets store CSI driver。 外掛會從 Key Vault 取得 TLS 憑證，並將驅動程式載入執行入口控制器的 pod 中。 此操作發生在 Pod 建立期間，磁碟區儲存公鑰和私鑰。

工作負載儲存（Workload storage）

此架構中的工作負載是無狀態的。 如果你必須儲存狀態，我們建議你將它持續存在於叢集之外。 工作負載狀態指南不屬於本文的討論範圍。

欲了解更多資訊，請參閱 AKS 中應用程式的存儲選項。

政策管理

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

要管理你的 AKS 叢集，你可以用 Azure Policy 來管理幾種方式：

  • 防止或限制在資源組或訂閱中部署 AKS 叢集。 為您的組織實施標準。 例如，您可以遵循命名約定或指定標籤。

  • 透過 Azure Policy for Kubernetes 保護你的 AKS 叢集。

一個政策有用的常見範例是容器映像的治理和驗證。 容器映像可能是漏洞的來源，某些組織要求使用容器映像掃描工具驗證不受信任的容器映像，然後才能在生產叢集中使用。 你可以透過使用 Azure Policy 來強制執行這個流程，並阻止不受信任的容器映像部署到叢集。 更多資訊請參閱隔離模式。

設定政策時，請根據工作負載的需求來套用。 考量下列因素：

  • 決定是設定一系列政策，稱為 倡議，或是選擇個別政策。 Azure Policy 提供兩個內建倡議：基本與受限。 每個計劃都是適用於 AKS 叢集的內建原則的集合。 我們建議您選擇一個倡議and並為叢集及資源選擇其他政策，例如容器登錄、Application Gateway或Key Vault，這些政策會與叢集互動。 根據您組織的要求選擇原則。

  • 決定你要審核還是拒絕這項行動。 在 稽核 模式中，允許動作，但標示為 不符合規範。 制定流程定期檢查不合規狀態並採取必要的措施。 在 [拒絕 ] 模式中，動作會因為違反原則而遭到封鎖。 選擇拒絕存取模式時要小心，因為這可能對操作來說過於限制。

  • 判斷你的工作量中是否有設計上不該符合規定的領域。 Azure Policy 可以指定免於政策強制執行的 Kubernetes 命名空間。 建議您仍然在 稽核 模式中套用原則，以便您知道這些實例。

  • 判斷是否有內建保單不涵蓋的要求。 你可以建立自訂的 Azure Policy 定義，套用你自訂的 OPA Gatekeeper 政策。 不要將自訂原則直接套用至叢集。 欲了解更多資訊，請參閱 建立並指派自訂政策定義。

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

  • 決定是否必須將 Azure 政策指派給特定的範圍。 確保你的 營運 政策也在 預營運 環境中得到驗證。 否則，當你部署到生產環境時，可能會遇到你在預生產階段沒考慮到的額外限制。

此參考實作在建立 AKS 叢集時啟用 Azure Policy。 限制性政策是在 稽核 模式中指派，以瞭解不符規範的情況。

該實施還制定了不屬於任何內建計劃的額外政策。 這些原則會設定為 拒絕 模式。 例如，有一項政策可確保僅從已部署的容器登錄執行個體中提取映像。

考慮建立您自己的自訂計畫。 將適用於您的工作負載的原則合併到單一分配中。

要從叢集內觀察 Azure Policy 的運作方式，你可以存取 gatekeeper-system 命名空間中所有 pod 的日誌，以及 kube-system 命名空間中 azure-policy 和 azure-policy-webhook pod 的日誌。

節點和 Pod 擴展性

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

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

自動縮放和手動方法都要求您監視 CPU 使用率或自訂指標並設定警報。 對於 Pod 擴展，您的應用程式操作員可以透過 Kubernetes API 調整 ReplicaSet 來增加或減少 Pod 副本的數量。 進行群集調整規模的一種方法是在 Kubernetes 調度程序出現故障時接收通知。 另一種方式是監看擱置的 Pod 一段時間。 你可以透過 Azure CLI 或 Azure portal 調整節點數量。

我們建議你採用自動縮放方式，因為部分手動機制內建於自動縮放器中。

作為一般方法，首先使用最少數量的 Pod 和節點進行效能測試。 使用這些值來建立基線期望值。 然後，結合使用效能指標和手動擴展來定位瓶頸並了解應用程式對擴展的反應。 最後，使用此資料設定自動縮放的參數。

水平 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在縮放操作結束前先檢查。 因此，結果可能是比率計算錯誤。 更多資訊請參見 Cooldown of scaling events。

如果您的工作負載是事件驅動的，那麼流行的開源選項是 Kubernetes 事件驅動自動擴展 (KEDA)。 如果是事件來源（如訊息佇列）驅動你的工作負載，而不是你的工作負載受限於 CPU 或記憶體，就考慮 KEDA。 KEDA 支援許多事件來源或縮放器。 使用 KEDA 可以在 KEDA 縮放器上調整的事件來源清單。 該清單包含 Azure Monitor scaler，這是一種根據 Azure Monitor 指標擴展 KEDA 工作負載的方便方式。

叢集自動調整器

cluster 自動縮放器 是 AKS 的一個附加元件，用於擴展節點池中的節點數量。 在叢集設定期間新增它。 針對每個使用者節點集區，您需要個別的叢集自動調整程式。

Kubernetes 排程器觸發叢集自動縮放程式。 當 Kubernetes 排程器因資源限制無法排程 pod 時，自動縮放器會自動在節點池中建立新節點。 相反地，叢集自動調整程式會檢查節點的未使用容量。 如果節點未達到預期容量，Pod 會被移動到另一個節點，並移除無法使用的節點。

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

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

業務連續性決策

為了保持業務連續性，請為基礎架構和應用程式定義 SLO。 欲了解更多資訊，請參閱信度目標定義建議。 請參閱最新的 SLA for online services 文章中 AKS 的服務水準協議（SLA）條件。

叢集節點

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

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

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

Pod 可用性

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

  • 設定 Pod 中斷預算： 此設定決定在更新或升級過程中，部署中可關閉多少副本。 欲了解更多資訊，請參閱 Pod 干擾預算。

    在部署中配置多個副本，以應對硬體故障等中斷。 對於計畫中的更新與升級事件，中斷預算有助於確保所需數量的 pod 副本存在以應付預期的應用程式負載。

  • 在工作負載命名空間設定資源配額： 命名空間的資源配額有助於確保部署時 pod 請求與限制被正確設定。 欲了解更多資訊，請參閱強制執行資源配額。

    Note

    如果您在叢集層級設定資源配額，並部署的外部負載沒有適當的資源請求和限制，可能會出現問題。 當你在命名空間層級設定配額時，它確保它們只適用於你的工作負載元件。

  • 設定 Pod 請求與限制：設定請求與限制，使 Kubernetes 能有效分配 CPU 和記憶體資源給 Pod。 它會讓你在節點上提高容器的密集度。 請求和限制還可以提高可靠性，同時由於更好的硬體使用而降低成本。

    若要估計工作負載的限制，請測試並建立基準。 從請求和限制的相同值開始。 然後逐步調整這些數值，直到你確定導致叢集不穩定的臨界值。

    您可以在部署清單中指定請求和限制。 更多資訊請參見 Set pod requests and limits。

可用區域

如果該地區支援，可使用可用性區域以防範某些類型的中斷。 然後，控制平面元件和節點集區中的節點都是 區域備援，這表示它們會分散在多個區域中。 如果整個可用性區域不可用，則該區域內另一個可用性區域的節點仍然可用。 每個節點集區映射到一個單獨的虛擬機器規模集，用於管理節點執行個體和可擴展性。 AKS 服務負責管理擴展集的操作與配置。 以下是啟用多個區域時的一些注意事項：

  • 整個基礎設施： 選擇支援可用性區域的地區。 欲了解更多資訊，請參見 Limitations。 要獲得服務可用性 SLA，您需要選擇 Standard 或 Premium 版本。 當使用可用性區域時，運作時間的 SLA 會更高。

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

    區域備援不僅適用於節點集區，也適用於控制平面。 AKS 控制平面跨越請求的區域，例如節點集區。 如果您在叢集中沒有使用可用性區域支援，控制平面元件並不保證會分佈在不同的可用性區域中。

  • 相依資源： 為了實現使用可用性區域的韌性效益，所有的服務相依性也必須支援可用性區域。 如果依賴服務不支援區域，則區域故障可能會導致該服務失敗。

    例如，假設您的工作負載使用不具有區域復原能力的資料庫。 如果發生故障，AKS 節點可能會移動到另一個區域，但資料庫不會隨節點移動到該區域，因此你的工作負載會中斷。

為了簡化此架構，AKS 部署於單一區域，節點池涵蓋三個 availability zones。 基礎設施中的其他資源，如 Azure Firewall 和 Application Gateway，也部署在同一區域，並支援多區域。 為容器註冊表啟用異地複寫。

多個區域

當你啟用可用性區域時，即便發生整個區域失效的情況，這樣的措施仍不足以提供充分的覆蓋。 為了獲得更高的可用性，請在不同區域執行多個 AKS 叢集。

  • 優先選擇配對區域，如果有的話。 使用配對區域的一個好處是平台更新期間的可靠性。 Azure 確保同一組區域中只有一個區域同時更新。 一些區域沒有配對。 如果您的區域未配對，您仍然可以透過選擇要使用的其他區域來部署多區域解決方案。 考慮使用持續整合和持續交付 (CI/CD) 流程，將其設定以協調從區域故障中的恢復。 像 Flux 這類專門的 DevOps 工具可以讓多區域部署變得更簡單。

  • 如果 Azure 資源支援地理冗餘，請提供冗餘服務的次要實例所在位置。 例如，透過啟用容器登錄的地理複製功能，它會自動將映像複製到選取的 Azure 區域。 即使主要地區出現中斷，仍可持續存取影像。

  • 根據您的要求，選擇可以跨區域或區域分配流量的流量路由器。 此架構部署 Load Balancer 是因為它能將非網頁流量分散到不同區域。 如果你需要跨區域分配流量，可以考慮 Azure Front Door。 其他選項請參見負載平衡器。

Note

AKS 多區域叢集範例情境將本文架構擴展至包含多個區域，呈現主動-主動且高度可用的配置。

災害復原

理想狀況下，如果主要區域發生故障，你可以迅速切換到另一個區域的實例。 你可以事先建立叢集，或等到需要時再建立。 請考量下列建議事項：

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

  • 使用可以高效率複製的無狀態工作負載。 如果你必須將狀態儲存在叢集中（我們不建議這麼做），請務必經常備份資料到其他區域。

  • 將復原策略整合進去，例如複製到另一個區域，作為 DevOps 流程的一部分，以符合你的 SLO 需求。

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

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

叢集備份

對許多架構來說，你可以建立一個新的叢集，然後透過基於 GitOps 的叢集啟動，再進行應用程式部署，將其恢復到運作狀態。 但是，如果存在關鍵資源狀態，例如配置地圖、任務和機密，無法在自動化流程中捕捉到，請考慮你的復原策略。 我們建議您在 Kubernetes 中執行無狀態工作負載。 如果您的體系結構涉及基於磁碟的狀態，您還必須考慮該內容的復原原則。

當叢集備份必須成為復原策略的一部分時，你必須在叢集內安裝符合業務需求的解決方案。 這個代理負責將叢集資源狀態推送到你選擇的目的地，並協調 Azure 磁碟基礎的持久磁碟快照。

VMware Velero 是常見的 Kubernetes 備份解決方案範例，您可以直接安裝及管理。 或者你可以使用 AKS 備份擴充功能來提供一個受管理的 Velero 實作。 AKS 備份擴充功能支援備份 Kubernetes 資源與持久磁碟區，排程與備份範圍則外置為 Azure Backup 的保險庫設定。

參考實作沒有實作備份，這需要額外的 Azure 資源來管理、監控、購買和保護。 這些資源可能包括 Azure Storage 帳號、Azure Backup 保險庫和設定，以及可信存取功能。 相反地，GitOps 與執行無狀態工作負載的意圖結合，是復原解決方案。

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

Kubernetes API 伺服器 SLA

你可以免費使用 AKS，但該等級不提供財務支持的服務等級協議（SLA）。 要取得SLA，您必須選擇標準層。 我們建議所有生產叢集都使用 Standard tier。 免費層保留給預生產叢集，Premium 層則只保留給 關鍵任務負載。 使用 Azure availability zones 時，Kubernetes API 伺服器的 SLA 會更高。 您的節點集區和其他資源都包含在各自的 SLA 中。

欲了解各服務的具體 SLA 資訊，請參閱 SLA for online services。

取捨

在跨區域，尤其是區域間部署架構，存在成本與可用性的權衡。 部分複製功能，如容器登錄中的地理複製，則可在高級 SKU 中提供，價格較高。 對於多區域部署，成本也會增加，因為流量跨區域移動時會產生頻寬費用。

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

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

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

更多資訊請參見Chaos Studio。

監視和收集日誌和指標

我們推薦 Azure Monitor Kubernetes 監控服務來監控容器工作負載的效能，因為你可以即時查看事件。 Azure Monitor 會擷取運行中的 pod 的容器日誌並彙整以便查看。 它還從指標 API 收集有關記憶體和 CPU 使用情況的資訊，以監控執行資源和工作負載的執行狀況。 你也可以用 Azure Monitor 來監控 Pods 擴展時的效能。 它包括對所收集資料的監控、分析和視覺化至關重要的遙測技術。

從 Pods 啟用日誌收集

ContainerLogV2 日誌架構 設計用來以簡化的方式擷取 Kubernetes Pod 的容器日誌。 日誌條目會整合到 Azure Log Analytics 工作空間中的 ContainerLogV2 表格中。

在 AKS 叢集中，有兩種主要方法可設定 Pod 記錄收集。 兩種方式都能自訂設定。 你可以篩選命名空間、調整收集間隔、啟用或禁止特定功能（例如 ContainerLogV2 或 ContainerLogV2-HighScale），並指定要收集哪些資料串流。

  • 如果你需要跨多個叢集的集中式、可重用監控設定，或偏好叢集配置外包於Azure原生資源中，請使用 資料收集規則（DCRs）。 Data Collection Rules (DCR) 是 Azure 的資源，由 Azure Resource Manager 的控制平面原生管理，你可以將它們包含在 Bicep 檔案中。 參考實作會使用 DCR。

  • 或者，您可以使用 ConfigMaps 來定義監控，這些是透過 Kubernetes API 控制平面設定的非機密 Kubernetes YAML 物件。 Azure Monitor Agent 是在叢集中執行的代理程式，負責監控 ConfigMap 物件。 它使用預先定義的設定來決定要收集哪些資料。

啟用這兩種方法時，ConfigMap 設定的優先順序高於 DCR。 避免混用 ConfigMap 與 DCR 設定來收集容器日誌，因為這可能導致難以排除故障的日誌問題。

警示和 Prometheus 指標

停電與故障對工作負載應用構成重大風險，因此主動識別基礎設施健康與效能相關問題至關重要。 當你監控環境並根據所學採取行動時，你能減少中斷並提升解決方案的可靠性。 為了預見叢集中可能的故障情況，請啟用 Kubernetes 的推薦 Prometheus 警報規則。

Pod 中託管的大多數工作負載都會發出 Prometheus 指標。 Azure Monitor 可以整合 Prometheus。 您可以檢視從容器、Pod、節點和叢集收集的應用程式和工作負載計量。

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

Azure基礎設施和Kubernetes控制平面日誌

透過 AKS，Azure 管理部分核心的 Kubernetes 服務。 Azure 將 AKS 控制平面元件的日誌實作為 resource logs。 這些選項能幫助你排除叢集問題，且日誌密度相對較低。 我們建議您在大多數叢集上啟用以下選項：

  • ClusterAutoscaler透過記錄獲得對縮放操作的可觀察性。 欲了解更多資訊，請參閱 檢索叢集自動調整器日誌和狀態。

  • KubeControllerManager：讓 Kubernetes 與 Azure 控制平面之間的互動變得可觀察。

  • kube-audit-admin：獲得對修改叢集活動的可觀察性。 不需要同時啟用 kube-audit 和 kube-audit-admin，因為 kube-audit 是一個包含非修改（讀取）操作的超集。

  • guard：捕捉 Microsoft Entra ID 和 Azure RBAC 的審計記錄。

在早期叢集或工作負載生命週期開發時，啟用其他日誌類別（如 KubeSchedulerkube-audit或 ）可能會有幫助。 新增的叢集自動擴展、Pod 放置和調度以及類似資料可以幫助您解決叢集或工作負載操作問題。 但如果你在故障排除需求結束後仍持續保留擴充故障排除日誌，可能會產生不必要的成本來匯入並儲存在 Azure Monitor 中。

Azure Monitor 包含一組現有的日誌查詢作為起點，但你也可以用它們作為基礎，幫助建立自己的查詢。 隨著函式庫的擴充，你可以透過使用一個或多個 query 包來儲存並重複使用日誌查詢。 您的自訂查詢函式庫能提供更可觀察的 AKS 叢集健康狀況與效能。 它支援達成您的 SLO（服務等級目標）。

欲了解更多關於 AKS 監控最佳實務的資訊，請參見 使用 Azure Monitor 監控 AKS。

網路計量

基本的叢集層級網路指標可透過原生平台與Prometheus指標取得。 你可以進一步利用 AKS 節點網路度量並透過 Prometheus 度量在節點層級揭露網路度量。 大多數叢集應具備網路可觀察性，以提供額外的網路故障排除能力，並偵測節點層級的意外網路使用情況或問題。

參考實作使用 Azure Monitor，該軟體也會收集一些與網路相關的指標。 參考實作禁止直接從 Azure Monitor 收集部分網路指標，改為使用 Azure Monitor 工作區，搭配 managed Prometheus 來收集網路可觀察性指標。

對於對傳輸控制協定 (TCP) 或使用者資料封包協定 (UDP) 資料包遺失、延遲或 DNS 壓力高度敏感的工作負載，Pod 等級網路指標非常重要。 在 AKS 中，你可以透過 Advanced Container Networking Services 功能來access這些詳細指標。 大多數工作負載不需要這種深度的網路可檢視性。 除非您的 Pod 需要高度優化的網路並且對封包層級有敏感需求，否則您不應該啟用進階網路可觀測性。

記錄的成本優化

參考實作會將 ContainerLogV2 數據表設定為使用基本計劃作為起點。 Microsoft Defender for Containers 以及為參考實作建立的警示不會查詢此表，因此 Basic 方案可能更具成本效益，因為它降低了擷取成本。

隨著記錄磁碟區和查詢需求的發展，請針對您的需求選取最符合成本效益的數據表計劃。 如果解決方案變得需要大量讀取，其中查詢經常掃描數據表數據，則預設分析計劃可能更合適。 分析計劃會免除查詢費用，針對查詢活動超過擷取成本的情境進行優化。 當你監控使用模式並根據需要調整桌面平面時，就能在監控解決方案的成本與功能之間取得平衡。

欲了解更多資訊，請參閱 根據日誌分析工作空間中的資料使用選擇表格計畫。

啟用自我修復

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

Note

AKS 具備 自動節點修復功能，為基礎設施節點提供內建自我修復功能。

AKS 叢集的例行更新

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

  • Kubernetes 版本（像是 Kubernetes 1.32.3 到 1.32.7 或 Kubernetes 1.32.7 到 1.33.1），可能會有 Kubernetes API 的變更和停用。 這一層的版本變更會影響整個叢集。

  • 每個節點上的虛擬硬碟 (VHD) 映像，結合了作業系統更新和 AKS 元件更新。 這些更新針對叢集的 Kubernetes 版本進行了測試。 此層的版本變更將應用於節點集區級別，不會影響 Kubernetes 版本。

  • 作業系統本身的原生更新程序，例如 Windows Update 或 apt。 作業系統供應商直接提供這些更新，並且沒有針對叢集的 Kubernetes 版本進行測試。 此層版本變更會影響單一節點，不影響 Kubernetes 版本。

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

欲全面了解修補與升級，請參閱AKS第二天操作指南中的AKS補丁與升級指引。 使用以下資訊作為與此架構相關的基準建議。

不可變的基礎結構

將 AKS 叢集作為不可變基礎設施執行的工作負載不會自動或手動更新其叢集。 將節點影像升級設為none，將叢集自動升級設為none。 在此設定中，您全權負責所有層的所有升級。

當你想要的更新可用時，你必須執行以下步驟：

  1. 在生產前環境中測試更新，並評估其在新叢集上的相容性。

  2. 部署包含更新的 AKS 版本和節點集區 VHD 的生產複本戳記。

  3. 當新的生產叢集準備就緒時，請將舊叢集的工作逐步遷移出來，並最終停止使用舊叢集。

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

就地升級

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

  • 排程 AKS 的 計劃維護功能，讓你能控制叢集上的升級。 此功能使您能夠在受控時間執行更新 (本質上是有風險的操作)，以減少意外故障的影響。

  • 設定 Pod 中斷預算，以便您的應用程式在滾動升級期間保持穩定。 但不要將預算設定過於激進，以免阻止節點升級的發生，因為大多數升級都需要在每個節點上進行警戒和排空過程。

  • 確認 Azure 資源配額與資源可用性。 就地升級會在移除舊節點之前，先部署稱為 激增節點的新節點實例。 這表示 Azure 配額和 IP 位址空間必須為新節點提供。 波動值33% 是大多數工作負載的良好起點。

  • 測試與工具組的相容性，例如你已經添加到叢集中的服務網格或安全代理。 另外，測試你的工作負載元件，例如入口控制器、服務網狀網路和工作負載模組。 在生產前環境中執行測試。

節點就地升級

使用 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 叢集時，避免使用 cluster 自動升級功能。 使用手動方法，讓你有時間在更新到達生產環境之前在預生產環境中測試新的 AKS 叢集版本。 這種方法還實現了最大程度的可預測性和控制。 但您必須勤於監控 Kubernetes 平台的新更新，並在新版本發佈時迅速採用它們。 與其採取長期支持的方法，不如保持「隨時更新」的心態。

Warning

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

您可以透過使用 AKS 系統（Azure Event Grid，收到叢集新增 AKS 版本的通知。 參考實作部署了這個事件網格系統，讓你可以透過事件串流通知解決方案訂閱 Microsoft.ContainerService.NewKubernetesVersionAvailable 事件。 請參考 AKS 發布說明，以了解具體的相容性疑慮、行為變更或功能棄用。

您最終可能會對 Kubernetes 版本、AKS 版本、叢集、叢集級元件和工作負載充滿信心，以探索自動升級功能。 對於生產系統來說，很少能超越 patch。 另外，當你自動升級 AKS 版本時，請檢查你的基礎設施版本設定（IaC），避免兩者不同步。請設定您的預定維護視窗以支援自動升級操作。

安全性監視

監控您的容器基礎架構是否有主動威脅和潛在安全風險。 如需詳細資訊，請參閱下列資源：

叢集和工作負載操作

關於叢集與工作負載運作（DevOps）的考量，請參閱 營運卓越設計原則支柱。

叢集自舉

當你架設好叢集後，它就如同運作中的叢集，但你可能還有更多步驟要完成才能部署工作負載。 準備叢集的程序稱為 引導。 引導設定通常包括將前置映像檔部署至叢集節點、建立命名空間，以及執行其他滿足組織使用情境要求的任務。

為了加速從新建立叢集轉換到正確配置的叢集，你必須定義獨特的自助流程並事先準備相關資產。 例如，如果您使用 Linkerd 或 Consul Connect 等服務網格，通常會在排程應用程式工作負載之前部署網格。 在建立叢集前，你必須驗證服務網狀網路的映像檔是否存在於先前建立的容器登錄檔中。 此驗證有助於防止部署延遲或失敗。

您可以使用以下方法之一設定引導過程：

Note

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

使用 AKS 的 GitOps Flux v2 叢集擴充程式的主要優點之一是，預先設定叢集和引導叢集之間實際上沒有間隙。 它為環境奠定未來堅實的管理基礎，並支持將引導過程作為資源模板納入，以配合您的 IaC 策略。

最後，當你使用 GitOps Flux v2 叢集擴充時，啟動過程中任何部分都不需要 kubectl。 你可以為緊急故障修復情況預留使用 kubectl 的存取權限。 透過 Azure 資源定義的範本，以及透過 GitOps 擴充套件引導清單，你可以在不使用 kubectl 的情況下執行所有正常的配置活動。

區分工作職責負載

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

從包含基本元件的基本工作負載開始，並在此基礎上進行建置。 初始任務是設定網路。 為中心和分支建立虛擬網路，並在這些網路內設置子網路。 例如，一個輪輻有系統節點池、使用者節點池、入口資源，以及私有 AKS API 伺服器的個別獨立子網。 在樞紐部署一個 Azure Firewall 的子網路。

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

使用 IaC

盡可能選擇冪等宣告式方法而不是命令式方法。 不要編寫指定設定選項的命令序列，而是使用描述資源及其屬性的聲明性語法。 參考實作使用 Bicep，但你也可以選擇使用 Terraform 或 Azure Resource Manager 模板（ARM 模板）。

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

如果你需要寫一連串指令，可以使用 Azure CLI。 這些指令涵蓋多種 Azure 服務，你可以透過腳本自動化。 Windows 和 Linux 支援 Azure CLI。 另一個跨平台選項是 Azure PowerShell。 您的選擇取決於您的首選技能。

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

工作負載 CI/CD

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

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

在此架構中，GitHub Actions 管理工作流程與部署。 其他熱門選項包括 Azure DevOps Services 以及 Jenkins。

叢集 CI/CD

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

下載此架構的Visio檔案.

與其使用像 kubectl 這種命令式方法，不如使用能自動同步叢集與儲存庫變更的工具。 為了管理工作流程，例如新版本的發布及該版本的驗證，然後部署到生產環境，可以考慮 GitOps 流程。

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

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

  • 監控所有已設定的儲存庫
  • 偵測新的配置變更
  • 觸發部署
  • 根據這些變更更新所需的運行設定

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

以下範例圖示展示了如何使用 GitOps 和 Flux 自動化叢集配置。

圖示，顯示 GitOps 流程。

下載此架構的Visio檔案.

  1. 開發者會提交原始碼的變更，例如配置 YAML 檔案，這些檔案會儲存在 Git 儲存庫中。 然後將變更推送到 Git 伺服器。

  2. Flux 與工作負載一起在 Pod 中運作。 Flux 對 Git 倉庫有唯讀 access 權限，以確保 Flux 只依開發者要求套用變更。

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

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

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

雖然你可以手動設定 GitOps 和 Flux，但我們推薦 AKS 的 GitOps with Flux v2 叢集擴充套件。

工作負載和叢集部署原則

將 任何 變更，例如架構元件、工作負載及叢集配置，部署到至少一個預生產的 AKS 叢集。 這個流程模擬變更，可能在將潛在問題部署到生產環境之前就發現。

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

進階部署技術，如 藍綠部署、A/B 測試和 金絲雀發布，需要額外的流程和可能更多的工具。 Flagger 是一個受歡迎的開源解決方案，用於解決進階部署情境。

成本管理

首先檢視 Well-Architected 框架中適用於 AKS 的成本優化設計清單和建議清單。 關於一般工作負載建議，請參閱成本優化的設計審查檢查清單。

您可以在 Azure 價格計算器中找到此基線架構所用元件的成本估算。 修改你的估價，納入符合你使用情境所需的元件。

考慮使用 AKS 成本分析，針對 Kubernetes 專用結構進行細緻叢集基礎設施成本分配。

Provision

  • 了解您的成本從何而來。 在 Kubernetes 叢集本身的部署、管理和操作方面，與 AKS 相關的成本極低。 影響成本的是叢集所消耗的虛擬機實例、storage、日誌資料和網路資源。 考慮為系統節點集區選擇更便宜的虛擬機器。 Ddv5系列是系統節點池中典型的虛擬機類型，參考實作則使用Standard_D2d_v5 SKU。

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

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

    對於包含 Azure SQL Database 或 Azure App Service 作為 AKS 工作負載架構一部分的非生產工作負載，請評估您是否符合使用 Azure 開發/測試訂閱 並享有服務折扣的資格。

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

  • 設定 Pod 要求和限制，讓 Kubernetes 配置更高密度的節點資源，以便您使用節點的完整容量。

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

  • 若工作負載必須長期存在，請承諾使用一年或三年的 Azure 預留虛擬機實例，以降低節點成本。 更多資訊請參見 Azure 預留虛擬機實例的節省成本。

  • 建立節點集區時使用標籤。 標籤可協助您建立自訂報告來追蹤所產生的成本。 您可以使用標籤來追蹤總費用並將任何成本對應到特定資源或團隊。 如果叢集是由多個團隊共用，請為每個使用者建立成本分攤報告，以識別共享雲端服務的計量成本。 欲了解更多資訊，請參閱 為節點池指定污點、標籤或標記。

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

  • 建立預算以保持在您的組織確定的成本限制範圍內。 您可以透過 Microsoft 成本管理建立預算。 你也可以建立警示，當超過特定門檻時收到通知。 欲了解更多資訊，請參見 使用 template 建立預算。

Monitor

你可以監控整個叢集，以及運算、storage、頻寬、日誌和防火牆的成本。 Azure 提供以下監控與分析成本的選項：

即時或定期監控您的費用，以便在月底已經計算完費用前採取行動。 持續監控每月趨勢，以保持預算內。

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

Optimize

請遵循Azure Advisor的建議。 探索其他優化方式：

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

    Important

    為了控制成本，快速或頻繁地更改叢集自動調整器的設定，例如節點池的最小與最大節點數，可能導致意想不到或適得其反的結果。 例如，若 scale-down-unneeded-time 設定為 10 分鐘，且根據工作負載特性每五分鐘調整一次最小與最大節點設定，節點數量永遠不會減少。 因為當叢集自動縮放器設定刷新時，每個節點不必要的時間計算會被重置。

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

  • 如果應用程式不需要突發擴展，可以考慮透過分析隨時間的效能指標來調整叢集規模。

  • 如果你的工作負載支援，當沒有預期它們會執行時，將你的使用者節點池調整至零節點。 如果叢集中沒有任何工作負載排程執行，建議使用 AKS 的啟動/停止功能來關閉所有計算資源，包括系統節點池和 AKS 控制平面。

欲了解更多資訊，請參閱AKS價格。

後續步驟