搭配多租使用者 Azure Kubernetes Service 使用 應用程式閘道 輸入控制器 （AGIC）

在此解決方案中，Azure Web 應用程式防火牆 （WAF） 會針對部署在多租使用者 Azure Kubernetes Service （AKS） 叢集上的 Web 應用程式提供集中式保護，免於常見的惡意探索和弱點。 在 Azure Kubernetes Service （AKS） 叢集上執行的 Web 應用程式，並透過 應用程式閘道 輸入控制器 （AGIC） 公開的 Web 應用程式，可以使用 Azure 應用程式閘道 上的 WAF 原則來保護惡意攻擊，例如 SQL 插入式攻擊和跨網站腳本。 Azure 應用程式閘道的 WAF 原則已預先設定開放全球應用程式安全性專案 （OWASP） 核心規則集，並可變更為其他支援的 OWASP 核心規則集 （CRS） 版本。

架構

下載此架構的 Visio 檔案。

工作流程

隨附 ARM 範本會部署具有四個子網的新虛擬網路：

• AksSubnet：裝載 AKS 叢集
• VmSubnet：裝載跳板虛擬機和私人端點
• AppGatewaySubnet：主機 應用程式閘道 WAF2 層。
• AzureBastionSubnet：裝載 Azure Bastion

Azure Kubernetes Service （AKS） 叢集會使用使用者定義的受控識別來建立其他資源，例如 Azure 中的負載平衡器和受控磁碟。 ARM 樣本可讓您部署具有下列功能的 AKS 叢集：

• 適用於 Azure 磁碟和 Azure 檔案儲存體 的容器記憶體介面 （CSI） 驅動程式
• AKS 管理的 Microsoft Entra 整合
• 適用於 Kubernetes 授權的 Azure 角色型存取控制 （RBAC）
• 受控識別取代服務主體
• Microsoft Entra 工作負載 ID （預覽）
• Azure 網路原則
• Azure 監視器容器深入解析附加元件
• 應用程式閘道 輸入控制器附加元件
• IP 和增強型子網支援的動態配置

AKS 叢集是由下列各項所組成：

• 只裝載重要系統 Pod 和服務的系統節點集區。 背景工作節點具有節點污點，可防止在此節點集區上排程應用程式Pod。
• 裝載使用者工作負載和成品的用戶節點集區。

虛擬機 （VM） 部署在裝載 AKS 叢集的相同虛擬網路中。 當您將 Azure Kubernetes Service 部署為私人叢集時，系統管理員可以使用此 VM 透過 Kubernetes 命令行工具來管理叢集。 虛擬機的開機診斷記錄會儲存在 Azure 儲存體 帳戶中。

Azure Bastion 主機會直接在透過 SSL 的 Azure 入口網站 中，提供安全且順暢的 SSH 連線至跳板 VM。 Azure Container Registry （ACR） 可用來建置、儲存及管理容器映射和成品（例如 Helm 圖表）。

架構包含輸入控制器所使用的 應用程式閘道。 應用程式閘道 會部署至專用子網，並透過所有租使用者工作負載共用的公用IP位址公開至公用因特網。 Web 存取防火牆 （WAF） 原則與根層級和 HTTP 接聽程式層級的 應用程式閘道 相關聯，以保護租使用者工作負載免受惡意攻擊。 此原則是在預防模式中設定，並使用 OWASP 3.1 來封鎖規則偵測到的入侵和攻擊。 攻擊者會收到「403 未經授權存取」例外狀況，且連線會關閉。 預防模式會在 WAF 記錄中記錄這些攻擊。

azure Kubernetes Service （AKS） 上執行的工作負載會使用 金鑰保存庫 作為秘密存放區，以透過用戶端連結庫、秘密存放區 CSI 驅動程式或 Dapr 擷取密鑰、憑證和秘密。 Azure Private Link 可讓 AKS 工作負載透過虛擬網路中的私人端點存取 Azure 平臺即服務 （PaaS） 服務，例如 金鑰保存庫。

範例拓撲包含下列私人端點：

• Blob 記憶體帳戶的私人端點
• Azure Container Registry 的私人端點 （ACR）
• 要 金鑰保存庫的私人端點
• 如果您選擇私人 AKS 叢集，則為 Kubernetes 叢集 API 伺服器的私人端點

此架構也包含下列 私用 DNS 區域，以將 PaaS 服務的完整功能變數名稱 （FQDN） 名稱解析至相關聯私人端點的私人 IP 位址：

• 私用 DNS 區域，用於將私人端點的名稱解析為 Azure Blob 儲存體 帳戶
• 私用 DNS 區域，用於將私人端點的名稱解析為 Azure Container Registry （ACR）
• 私用 DNS 區域，用於將私人端點的名稱解析為 Azure 金鑰保存庫
• 如果您將叢集部署為私人，私用 DNS 區域，用於將私人端點的名稱解析為 Kubernetes Server API

裝載 AKS 叢集的虛擬網路與上述 私用 DNS 區域之間存在 虛擬網絡 連結。 Log Analytics 工作區可用來從下列來源收集診斷記錄和計量：

• Azure Kubernetes Service 叢集
• 跳板式虛擬機
• Azure 應用程式閘道
• Azure Key Vault
• Azure 網路安全性群組

元件

• Azure Container Registry 是以開放原始碼 Docker Registry 2.0 為基礎的受控私人 Docker 登錄服務。 您可以使用 Azure 容器登錄搭配現有的容器開發和部署管線，或使用 Azure Container Registry 工作在 Azure 中建置容器映像。 視需要建置，或使用觸發程式完全自動化組建，例如原始程式碼認可和基底映像更新。

• Azure Kubernetes Services 藉由將作業額外負荷卸除至 Azure，簡化在 Azure 中部署受控 Kubernetes 叢集。 由於託管的 Kubernetes 服務，Azure 會處理重要的工作，例如健康情況監控和維護。 由於 Kubernetes 主機由 Azure 所管理，因此您只需要管理及維護代理程式節點。

• Azure 金鑰保存庫 安全地儲存及控制秘密的存取，例如 API 金鑰、密碼、憑證和密碼編譯密鑰。 Azure 金鑰保存庫 也可讓您輕鬆地布建、管理及部署公用和私人傳輸層安全性/安全套接字層 （TLS/SSL） 憑證，以搭配 Azure 和內部連線的資源使用。

• Azure 應用程式閘道 Azure 應用程式閘道 是一個 Web 流量負載平衡器，可讓您管理多個下游 Web 應用程式和 REST API 的輸入流量。 傳統負載平衡器會在傳輸層（開放系統互連 （OSI） 第 4 層 - TCP 和 UDP 上運作，並且會根據來源 IP 位址和埠將流量路由傳送至目的地 IP 位址和埠。 應用程式閘道 是應用層 （OSI 第 7 層） 負載平衡器。 （OSI 代表開放式系統互連、 TCP 代表傳輸控制通訊協定，而 UDP 代表使用者數據報通訊協定。

• Web 應用程式防火牆 或 WAF 是一項服務，可提供 Web 應用程式的集中式保護，免於常見的惡意探索和弱點。 WAF 是以 OWASP （Open Worldwide Application Security Project） 核心規則集的規則為基礎。 Azure WAF 可讓您針對通過原則的每個要求，建立評估的自定義規則。 這些規則的優先順序高於受控規則集中的其餘規則。 自訂規則包含規則名稱、規則優先順序和比對條件的陣列。 如果符合這些條件，則會採取動作（允許或封鎖）。

• Azure Bastion 是一個完全受控的平臺即服務（PaaS），您可以在虛擬網路內布建。 Azure Bastion 提供安全且順暢的遠端桌面通訊協定 （RDP） 和安全殼層 （SSH） 連線至虛擬網路中的 VM，直接從透過 TLS Azure 入口網站。

• Azure 虛擬機器 提供隨選、可調整的運算資源，讓您擁有虛擬化的彈性，而不需要購買和維護實體硬體。

• Azure 虛擬網絡 是 Azure 專用網的基本建置組塊。 透過 虛擬網絡，Azure 資源（例如 VM）可以安全地彼此通訊、因特網和內部部署網路。 Azure 虛擬網絡 類似於內部部署的傳統網路，但它包含 Azure 基礎結構的優點，例如延展性、可用性和隔離。

• 虛擬網絡 介面可讓 Azure 虛擬機與因特網、Azure 和內部部署資源通訊。 您可以將數張網路適配器新增至一個 Azure VM，讓子 VM 可以有自己的專用網路介面裝置和 IP 位址。

• Azure 受控磁碟 提供 Azure 在 Azure VM 上管理的區塊層級記憶體磁碟區。 可用的磁碟類型包括 Ultra 磁碟、進階固態硬碟 （SSD）、標準 SSD 和標準硬碟 （HDD）。

• Azure Blob 儲存體 是雲端Microsoft的物件記憶體解決方案。 Blob 儲存體已針對儲存大量非結構化資料進行最佳化。 「非結構化資料」是指不符合特定資料模型或定義的資料，例如文字或二進位資料。

• Azure Private Link 可讓您透過虛擬網路中的私人端點存取 Azure PaaS 服務（例如，Azure Blob 儲存體 和 金鑰保存庫），以及 Azure 託管的客戶擁有/合作夥伴服務。

替代項目

在此架構中，應用程式閘道 輸入控制器 （AGIC） 是使用適用於 Azure Kubernetes Service （AKS） 的 AGIC 附加元件來安裝。 您也可以透過 Helm 圖表安裝 應用程式閘道 輸入控制器。 針對新的設定，您可以使用 Azure CLI 中的一行來部署新的 應用程式閘道 和新的 AKS 叢集（已啟用 AGIC 做為附加元件）。 附加元件也是完全受控的服務，可提供額外的優點，例如自動更新和增加的支援。 Microsoft完全支援部署 AGIC（Helm 和 AKS 附加元件）的兩種方式。 此外，附加元件可讓您更妥善地與AKS整合，作為第一類附加元件。

應用程式閘道 輸入控制器 （AGIC） 附加元件仍會部署為 AKS 叢集中的 Pod。 不過，Helm 部署版本與 AGIC 的附加元件版本之間有一些差異。 下列清單包含兩個版本之間的差異：

• AKS 附加元件上無法修改 Helm 部署值：

  • usePrivateIp 默認會設定為 false ;註釋可以覆寫 use-private-ip 此專案
  • shared 附加元件不支援

• 透過 Helm 部署的 AGIC 支援 ProhibitedTargets，這表示 AGIC 可以特別針對 AKS 叢集設定 應用程式閘道，而不會影響其他現有的後端。

• 因為 AGIC 附加元件是受控服務，所以它會自動更新為最新版的 AGIC 附加元件，不像透過 Helm 部署的 AGIC（您必須手動更新 AGIC 的位置）。

• 每個 AKS 叢集只能部署一個 AGIC 附加元件，而每個 AGIC 附加元件目前只能以一個 應用程式閘道 實例為目標。 對於每個叢集需要多個 AGIC 的部署，或以一個 應用程式閘道 為目標的多個 AGIC，您可以繼續使用透過 Helm 部署的 AGIC。

Azure 應用程式閘道 Kubernetes 輸入控制器 （AGIC） 的單一實例可以從多個 Kubernetes 命名空間擷取事件。 如果 AKS 系統管理員決定使用 應用程式閘道 做為輸入，所有命名空間都會使用相同的實例 應用程式閘道。 輸入控制器的單一安裝會監視可存取的命名空間，並將設定與其相關聯的 應用程式閘道。 如需詳細資訊，請參閱在具有 應用程式閘道 輸入控制器的 AKS 叢集中啟用多個命名空間支援。

若要啟用多重命名空間支援，請執行下列動作：

• 以下列其中一種方式修改 helm-config.yaml 檔案：

  • watchNamespace從 helm-config.yaml 檔案中刪除密鑰。 AGIC 會觀察所有命名空間。
  • 設定 watchNamespace 為空字串。 AGIC 會觀察所有命名空間。
  • 新增多個命名空間，並以逗號 （watchNamespace: default,secondNamespace） 分隔。 AGIC 會以獨佔方式觀察這些命名空間。

• 使用此文稿套用 Helm 樣本變更： helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure

部署后能夠觀察多個命名空間，AGIC 會執行下列動作：

• 列出所有可存取命名空間的輸入資源
• 篩選為以 kubernetes.io/ingress.class 批注的輸入資源：azure/application-gateway
• 組合 應用程式閘道 組態
• 透過 ARM 將設定套用至相關聯的 應用程式閘道

案例詳細資料

多租使用者 Kubernetes 叢集是由多個使用者和工作負載共用，這些使用者和工作負載通常稱為「租使用者」。 此定義包含由組織內不同小組或部門共用的 Kubernetes 叢集。 它也包含由軟體即服務 （SaaS） 應用程式的個別客戶實例共用的叢集。 叢集多租使用者是管理許多單一租使用者專用叢集的替代方案。 多租使用者 Kubernetes 叢集的操作員必須彼此隔離租使用者。 此隔離可將遭入侵或惡意租使用者對叢集和其他租用戶的損害降到最低。 當數個使用者或小組與固定數目的節點共用同一個叢集時，有一個小組可能會使用超過其公平資源份額的問題。 資源配額 是系統管理員解決此問題的工具。

當您計劃建置多租使用者 Azure Kubernetes Service （AKS） 叢集時，您應該考慮 Kubernetes 所提供的資源隔離層：叢集、命名空間、節點、Pod 和容器。 您也應該考慮在多個租用戶之間共用不同類型的資源的安全性影響。 例如，在相同節點上排程來自不同租使用者的 Pod 可能會減少叢集中所需的機器數目。 另一方面，您可能需要防止某些工作負載共置。 例如，您可能不允許組織外部不受信任的程式代碼在處理敏感性資訊的容器上執行。 Azure 原則 可用來將部署限制為僅信任登錄的AKS。

雖然 Kubernetes 無法保證租使用者之間的完全安全隔離，但它確實提供可能足以用於特定使用案例的功能。 最佳做法是，您應該將每個租使用者及其 Kubernetes 資源分成自己的命名空間。 然後 ，您可以使用 Kubernetes RBAC 和 網路原則 來強制執行租用戶隔離。 （RBAC 代表角色型訪問控制。例如，下圖顯示在相同叢集上裝載相同應用程式多個實例的一般 SaaS 提供者模型，每個租使用者各一個實例。 每個應用程式都位於個別的命名空間中。 當租使用者需要較高層級的實體隔離和保證效能時，其工作負載可以部署到一組專用的節點、專用集區，甚至是專用叢集。

下載此架構的 Visio 檔案。

應用程式閘道 輸入控制器 （AGIC） 是 Kubernetes 應用程式，可讓 Azure Kubernetes Service （AKS） 客戶使用 Azure 應用程式閘道 將其容器化應用程式公開至因特網。 AGIC 會監視其裝載的 Kubernetes 叢集，並持續更新 應用程式閘道，讓選取的服務公開給因特網。 輸入控制器會在客戶的 AKS 實例上，在其自己的 Pod 中執行。 AGIC 會監視 Kubernetes 資源的子集是否有變更。 AKS 叢集的狀態會轉譯為 應用程式閘道 特定設定，並套用至 Azure Resource Manager。 此架構範例示範使用 Azure 應用程式閘道 和 應用程式閘道 輸入控制器附加元件來部署公用或私人 Azure Kubernetes Service （AKS） 叢集的實證做法。

Azure 應用程式閘道 Kubernetes 輸入控制器 （AGIC） 的單一實例可以從中擷取事件並觀察多個命名空間。 如果 AKS 系統管理員決定使用 應用程式閘道 做為輸入，所有命名空間都會使用相同的實例 應用程式閘道。 輸入控制器的單一安裝會監視可存取的命名空間，並將設定與其相關聯的 應用程式閘道。

潛在使用案例

使用 應用程式閘道 輸入控制器 （AGIC） 來公開和保護在多租用戶環境中 Azure Kubernetes Service （AKS） 叢集上執行的因特網面向工作負載。

考量

雖然下列一些考慮並未完全與 Azure Kubernetes Service （AKS） 中的多租用戶相關，但我們相信部署此解決方案時，這些考慮是基本需求。 這包括我們的安全性、效能、可用性和可靠性、記憶體、排程器、服務網格和監視考慮。

多租用戶考慮

• 設計多租使用者的 AKS 叢集。 Kubernetes 提供功能，可讓您以邏輯方式隔離在相同叢集中的小組和工作負載。 目標應該是提供最少的許可權數目，範圍限定於每個小組所需的資源。 Kubernetes 中的命名空間會建立邏輯隔離界限。
• 使用邏輯隔離來分隔小組和專案。 嘗試將您部署的實體 AKS 叢集數目降至最低，以隔離小組或應用程式。 叢集的邏輯區隔通常提供比實體隔離叢集更高的Pod密度。
• 每當您需要實作嚴格的實體隔離時，請使用專用節點集區或專用 AKS 叢集。 例如，您可以將背景工作節點集區或整個叢集，奉獻給多租用戶環境中的小組或租使用者。
  • 您可以使用污點和容忍的組合來控制 Pod 部署到特定節點集區。 請注意，AKS 中的節點只能在節點集區建立時受到污染。 或者， 標籤和 nodePool 選取器 可用來控制將工作負載部署到特定節點集區。

安全性考量

雖然安全性考慮並未完全與 AKS 中的多租用戶有關，但我們相信在部署此解決方案時是基本需求。

網路安全性

• 為 AKS 工作負載使用的任何 PaaS 服務建立私人端點，例如 金鑰保存庫、服務匯流排 或 Azure SQL 資料庫。 如此一來，應用程式與這些服務之間的流量就不會公開至公用因特網。 如需詳細資訊，請參閱 什麼是 Azure Private Link。
• 設定 Kubernetes 輸入資源以透過 HTTPS 公開工作負載，並針對每個租使用者使用不同的子域和數位證書。 應用程式閘道 輸入控制器 （AGIC） 會自動設定安全套接字層 （SSL） 終止 Azure 應用程式閘道 接聽程式。
• 將 Azure 應用程式閘道 設定為使用 Web 應用程式防火牆 原則來保護公開工作負載（在 AKS 上執行的工作負載）免於遭受惡意攻擊。
• 若要與現有的虛擬網路或內部部署網路整合，請使用 AKS 中的 Azure CNI 網路。 此網路模型也允許在企業環境中更區分資源和控件。
• 透過控制哪些元件可以彼此通訊，使用網路原則來隔離及保護服務內部通訊。 根據預設，Kubernetes 叢集中的所有 Pod 都可以傳送和接收流量，而不受限制。 若要改善安全性，您可以使用 Azure 網路原則或 Calico 網路原則來定義規則，以控制不同微服務之間的流量流程。 如需詳細資訊，請參閱 網路原則。
• 請勿對您的 AKS 節點公開遠端連線能力。 在管理虛擬網路中建立防禦主機或跳躍箱 (jump box)。 您可以使用防禦主機安全地將流量路由到 AKS 叢集，以完成遠端管理工作。
• 請考慮在生產環境中使用 私人 AKS 叢集 ，或至少使用 Azure Kubernetes Service 中授權的 IP 位址範圍 ，安全地存取 API 伺服器。
• Azure DDoS 保護 (結合應用程式設計最佳做法) 可提供增強的 DDoS 風險降低功能，以針對 DDoS 攻擊提供更多的防禦。 您應該在任何周邊虛擬網路上啟用 Azure DDoS 保護 。

驗證與授權

• 使用 Microsoft Entra 整合部署 AKS 叢集。 如需詳細資訊，請參閱 AKS 管理的 Microsoft Entra 整合。 使用 Microsoft Entra 識別碼會將身分識別管理元件集中。 使用者帳戶或群組狀態的任何變更都會在存取 AKS 叢集時自動更新。 使用 角色 或 ClusterRoles 和 系結 ，將使用者或群組的範圍設定為所需的最小許可權數目。
• 使用 Kubernetes RBAC 來定義使用者或群組對叢集中資源的許可權。 建立角色和系結，以指派最少的許可權數目。 整合 Kubernetes RBAC 與 Microsoft Entra 識別碼 ，因此用戶狀態或群組成員資格的任何變更都會自動更新，且叢集資源的存取權是最新的。
• 使用 Azure RBAC 來定義使用者或群組對一或多個訂用帳戶中 AKS 資源所需的最低許可權。 如需詳細資訊，請參閱 Kubernetes RBAC 和使用適用於 Kubernetes 授權的 Azure RBAC（AuthZ）。
• 請考慮使用 Microsoft Entra 工作負載 ID 將 Azure 資源的受控識別指派給個別微服務，然後可用來存取受控資源（例如 Azure 金鑰保存庫、SQL 資料庫、服務匯流排 和 Cosmos DB）。 完全不需要儲存和擷取 Kubernetes 秘密中的 連接字串 或認證。
• 請考慮使用適用於 Azure 的秘密存放區 CSI 驅動程式 金鑰保存庫 來存取秘密，例如來自 金鑰保存庫 的認證和連接字串，而不是來自 Kubernetes 秘密。
• 請考慮使用 Dapr 秘密存放區建置組塊，搭配 Azure 金鑰保存庫 存放區搭配 Kubernetes 上的受控識別，從 金鑰保存庫 擷取秘密（例如認證和 連接字串）。

工作負載和叢集

• 保護 Kubernetes API-Server 的存取權是保護叢集安全最重要的工作之一。 整合 Kubernetes 角色型存取控制 （Kubernetes RBAC） 與 Microsoft Entra 識別碼，以控制 API 伺服器的存取。 這些控制項可讓您以安全存取 Azure 訂用帳戶的方式保護 AKS。
• 限制存取容器可執行的動作。 使用 Pod 安全性許可 來啟用 Pod 建立和更新的細微授權。 提供最少的許可權數目，並避免使用根/特殊許可權提升。 如需最佳做法詳細資訊，請參閱保護 Pod 對資源的存取。
• 盡可能避免以根使用者身分執行容器。
• 使用 AppArmor Linux 核心安全性模組來限制容器可執行的動作。
• 定期將您的 AKS 叢集升級至最新的 Kubernetes 版本，以利用新功能和錯誤修正。
• AKS 會自動在每個 Linux 節點上下載並安裝安全性修正程式，但必要時不會自動重新啟動節點。 使用 Kured 來監看擱置重新啟動、封鎖和清空節點，最後套用您的更新。 針對 Windows Server 節點，定期執行 AKS 升級作業，以安全地封鎖和清空 Pod，以及部署任何更新的節點。
• 請考慮針對所有 Pod 內部通訊使用 HTTPS 和 gRPC 安全傳輸通訊協定，並使用更進階的驗證 （AuthN） 機制，不需要您在每個要求上傳送一般認證，例如 Open Authorization （OAuth） 或 JWT。 藉由利用 Istio、Linkerd 或 Consul或 Dapr 等服務網格，即可達成安全的服務內部通訊。

Azure Container Registry

• 掃描您的容器映像是否有弱點，並只部署已通過驗證的映像。 定期更新基底映像和應用程式運行時間，然後在 AKS 叢集中重新部署工作負載。 您的 CI/CD 部署工作流程應該包含掃描容器映像的程式。 適用於雲端的 Microsoft Defender DevOps 安全性可用來掃描程式代碼，以在自動化管線中建置/部署期間是否有弱點。 或者，Prisma Cloud 或 Aqua 之類的工具可用來掃描，只允許部署已驗證的映像。
• 當您使用基底映像作為應用程式映像時，在更新基底映像時，使用自動化功能建置新的映像。 因為這些基底映像通常包含安全性修正，請更新任何下游應用程式容器映像。 如需基底映像更新的詳細資訊，請參閱使用 Azure Container Registry 工作在基底映像更新時自動執行映像建置。

效能考量

雖然效能考慮與 Azure Kubernetes Service （AKS） 中的多租用戶無關，但我們相信在部署此解決方案時是基本需求：

• 針對低延遲工作負載，請考慮在鄰近放置群組中部署專用節點集區。 在 Azure 中部署應用程式時，將虛擬機 （VM） 實例分散到區域或可用性區域會建立網路等待時間，這可能會影響應用程式的整體效能。 鄰近放置群組是邏輯群組，用來確保 Azure 計算資源實際位於彼此附近。 某些使用案例（例如遊戲、工程模擬和高頻率交易 （HFT）需要快速完成的低延遲和工作。 針對這類高效能運算 （HPC） 案例，請考慮針對叢集的節點集區使用鄰近放置群組 （PPG）。
• 一律使用較小的容器映像，因為它可協助您建立更快速的組建。 由於受攻擊面減少，較小的影像也較不容易受到攻擊媒介的影響。
• 使用 Kubernetes 自動調整，在流量增加時動態相應放大 AKS 叢集的背景工作節點數目。 使用 水準 Pod 自動調整程式和 叢集自動調整程式，節點和 Pod 磁碟區會即時動態調整，以符合流量狀況，並避免容量問題所造成的停機時間。 如需詳細資訊，請參閱在 Azure Kubernetes Service 中使用叢集自動調整程式（AKS）。

可用性和可靠性考慮

雖然可用性和可靠性考慮與 Azure Kubernetes Service （AKS） 中的多租用戶無關，但我們相信部署此解決方案時，它們是基本需求。 請考慮下列方式來優化 AKS 叢集和工作負載的可用性。

容器

• 使用 Kubernetes 健康情況探查來檢查您的容器是否運作良好：

  • livenessProbe 會指出容器是否正在執行。 如果活躍度探查失敗， kubelet 會終止容器，而容器會受到其重新啟動原則。
  • readinessProbe指出容器是否已準備好回應要求。 如果整備探查失敗，端點控制器會從符合 Pod 的所有服務端點中移除 Pod 的 IP 位址。 初始延遲之前的預設整備狀態為 [失敗]。
  • 啟動 探查 會指出是否已啟動容器內的應用程式。 如果提供啟動探查，則會停用所有其他探查，直到成功為止。 如果啟動探查失敗， kubelet 會終止容器，且容器受限於其重新啟動原則。

• 資源爭用可能會影響服務可用性。 定義容器資源條件約束，讓任何單一容器都無法壓倒叢集記憶體和 CPU 資源。 您可以使用 AKS 診斷來識別叢集中的任何問題。

• 使用資源限制來限制容器所允許的總資源，因此一個特定的容器無法耗盡其他容器。

Container Registry：

• 我們建議將容器映像儲存在 Azure Container Registry 中，然後使用 Azure Container Registry 異地復寫至每個 AKS 區域。 異地復寫是進階 SKU ACR 登錄的功能。
• 掃描您的容器映像是否有弱點，並只部署已通過驗證的映像。 定期更新基底映像和應用程式運行時間，然後在 AKS 叢集中重新部署您的工作負載。
• 限制 Pod 和部署可以使用的映像登錄。 只允許信任的登錄，您可以在其中驗證和控制可用的映像。
• 當您針對應用程式映像使用基底映射時，請使用自動化來建置新的映像，當基底映射更新時。 因為這些基底映像通常包含安全性修正，請更新任何下游應用程式容器映像。 建議您先掃描容器映射中是否有弱點，作為 CI/CD 管線的一部分，再將映像發佈至容器登錄。 適用於容器 的 Azure Defender 可以整合至 CI/CD 工作流程。
• 利用 Azure Container Registry 中的 ACR 工作 ，將 Docker 容器的 OS 和架構修補自動化。 ACR 工作支援自動化建置執行，當容器的基底映像更新時，例如當您在其中一個基底映射中修補 OS 或應用程式架構時。

區域內復原能力

• 請考慮跨區域內的所有 可用性區域 部署 AKS 叢集的節點集區，並在節點集區前使用 Azure Standard Load Balancer 或 Azure 應用程式閘道。 如果單一數據中心中斷，此拓撲可提供更佳的復原能力。 如此一來，叢集節點會分散到多個數據中心，在區域內有三個不同的 可用性區域。
• 在 Azure Container Registry 中啟用區域備援，以取得區域內的復原和高可用性。
• 使用 Pod 拓撲散佈條件約束 來控制 Pod 在失敗網域之間分散到 AKS 叢集的方式，例如區域、可用性區域和節點。
• 請考慮針對裝載任務關鍵性工作負載的 AKS 叢集使用運行時間服務等級協定 （SLA）。 運行時間 SLA 是選擇性功能，可針對叢集啟用財務支援的更高 SLA。 運行時間 SLA 可保證 Kubernetes API 伺服器端點的 99.95% 可用性，適用於使用 可用性區域 的叢集。 而且它保證未使用 可用性區域 的叢集 99.9% 可用性。 AKS 會跨更新和容錯網域使用主要節點複本，以確保符合 SLA 需求。

災害復原和商務持續性

• 請考慮將解決方案部署到地理位置內至少 兩個配對的 Azure 區域 。 您也應該採用全域負載平衡器，例如 Azure 流量管理員 或 Azure Front Door，使用主動/主動或主動/被動路由方法來保證商務持續性和災害復原。
• 請務必編寫腳本、記錄並定期測試 QA 環境中的任何區域故障轉移程式，以避免如果核心服務受到主要區域中中斷的影響，則避免無法預期的問題。
• 這些測試也旨在驗證災害復原 （DR） 方法是否符合恢復點目標 （RPO）/復原時間目標 （RTO） 目標，以及故障轉移所需的最終手動程式和干預。
• 請務必測試容錯回復程式，以瞭解其是否如預期般運作。
• 將您的容器映像儲存在 Azure Container Registry 中，並將登錄異地複寫至每個 AKS 區域。 如需詳細資訊，請參閱 Azure Container Registry 中的異地複寫。
• 可能的話，請勿將服務狀態儲存在容器內。 而是使用支援多重區域複寫的 Azure 平台即服務 (PaaS)。
• 如果您使用 Azure 儲存體，請針對將儲存體從主要區域遷移至備份區域的方法進行準備和測試。
• 請考慮使用 GitOps 部署叢集組態。 使用 GitOps 可在主要叢集和DR 叢集之間提供統一性，以及在叢集遺失時快速重建新叢集的方法。
• 請考慮使用 Azure Kubernetes Service 備份或 Velero 等工具來備份/還原叢集組態。

儲存體考量

雖然記憶體考慮與 Azure Kubernetes Service （AKS） 中的多租用戶無關，但我們相信部署此解決方案時，它們是基本需求：

• 請考慮使用 暫時 OS 磁碟 來部署 AKS 叢集，以提供較低的讀取/寫入延遲，以及更快的節點調整和叢集升級。
• 了解應用程式的需求以挑選正確的儲存體。 針對生產工作負載使用高效能、以 SSD 備份的儲存體。 規劃網路型記憶體系統，例如 Azure 檔案儲存體，當多個 Pod 需要同時存取相同的檔案時。 如需詳細資訊，請參閱 Azure Kubernetes Service （AKS） 中應用程式的記憶體選項。
• 每個節點大小都支援最大的磁碟數目。 不同的節點大小也會提供不同的本機儲存體大小和網路頻寬。 規劃應用程式需要部署適當大小的節點。
• 若要減少管理額外負荷並讓您調整規模，請勿以靜態方式建立並指派永續性磁碟區。 請使用動態佈建。 在您的記憶體類別中，定義適當的回收原則，以在刪除 Pod 之後將不需要的記憶體成本降到最低。

排程器考慮

雖然某些排程器考慮與 Azure Kubernetes Service （AKS） 中的多租用戶無關，但我們相信部署此解決方案時，這些考慮是基本需求：

• 請務必檢閱並實 作最佳做法，讓叢集操作員和應用程式開發人員在 Azure Kubernetes Service 上成功建置和執行應用程式。
• 針對所有命名空間，在命名空間層級規劃和套用 資源配額 。 如果 Pod 未定義資源要求和限制，則拒絕部署。 監視資源使用量，然後視需要調整配額。 當數個小組或租使用者與固定數目的節點共用 AKS 叢集時，可以使用資源配額將公平共用的資源指派給每個小組或租使用者。
• 在 CPU 和記憶體方面，採用 限制範圍 來限制命名空間中的資源配置（對 Pod 或容器）。
• 針對您用來部署應用程式的 YAML 指令清單或 Helm 圖表中的 Pod，明確定義 CPU 和記憶體使用量的資源 要求和限制 。 當您在 Pod 中指定容器的資源要求時，Kubernetes 排程器會使用此資訊來決定要放置 Pod 的節點。 當您為容器指定資源限制（例如 CPU 或記憶體）時，kubelet 會強制執行這些限制，讓執行中的容器無法使用比您設定的限制更多的資源。
• 若要維護應用程式的可用性，請定義 Pod中斷預算，以確保叢集中可用的Pod數目下限。
• 優先順序類別 可用來指出Pod的重要性。 如果無法排程 Pod，排程器會嘗試先佔 （evict） 較低的優先順序 Pod，以便讓暫止 Pod 的排程成為可能。
• 使用 Kubernetes 污點和容忍 將資源密集型應用程式放在特定節點上，並避免發生雜亂的鄰近問題。 讓節點資源可供需要它們的工作負載使用，而且不允許在節點上排程其他工作負載。
• 使用節點選取器、節點親和性或Pod間親和性來控制節點上Pod的排程。 使用 Pod 間親和性和反親 和性設定來共置具有聊天通訊的 Pod、將 Pod 放在不同的節點上，以及避免在相同節點上執行相同 Pod 種類的多個實例。

服務網格考慮

雖然服務網格考慮並未完全與 AKS 中的多租用戶相關，但我們相信在部署此解決方案時是基本需求：

• 請考慮在 AKS 叢集中使用開放原始碼服務網格（例如 Istio、 Linkerd 或 Consul），以透過相互 TLS 改善微服務的可觀察性、可靠性和安全性。 您也可以實作流量分割策略（例如藍/綠部署和 Canary 部署）。 簡言之，服務網狀結構是專用的基礎結構層，可讓服務對服務通訊安全、快速且可靠。 若要查看 AKS 整合的 Istio 附加元件，請參閱： Istio 服務網格 AKS 附加元件

• 請考慮採用 Dapr 來建置復原、微服務無狀態和具狀態應用程式。 您可以使用任何程式設計語言和開發人員架構。

DevOps 考慮

• 使用 GitHub Actions 或 Azure DevOps 等 DevOps 系統，將工作負載部署至 Azure Kubernetes Service （AKS），並在 CI/CD 管線中使用 Helm 圖表。 如需詳細資訊，請參閱 建置並部署至 Azure Kubernetes Service。

• 介紹應用程式生命週期管理中的 A/B 測試和 Canary 部署，以在讓所有使用者都能使用應用程式之前，先正確測試應用程式。 有數種技術可用來將流量分割到相同服務的不同版本。

• 或者，您可以使用服務網格實作所提供的流量管理功能。 如需詳細資訊，請參閱

  • Istio 流量管理

• 使用 Azure Container Registry 或其他容器登錄（例如 Docker Hub），來儲存部署至叢集的私人 Docker 映像。 AKS 可以使用其Microsoft Entra 身分識別，向 Azure Container Registry 進行驗證。

監視功能考量

雖然監視考慮並未完全與 Azure Kubernetes Service （AKS） 中的多租用戶有關，但我們相信在部署此解決方案時是基本需求：

• 請考慮 Azure 整合 式監視選項 ，以監視 AKS 叢集和工作負載的健康情況狀態。
• 將所有 PaaS 服務 （例如 Azure Container Registry 和 金鑰保存庫） 設定為將診斷記錄和計量收集到 Azure 監視器 Log Analytics。

成本最佳化

此架構的成本取決於組態層面，如下所示：

• 服務層
• 延展性，表示服務動態配置以支援指定需求的實例數目
• 自動化指令碼
• 災害復原層級

評估這些層面之後，請移至 Azure 定價計算機 來預估您的成本。 此外，如需更多定價優化選項，請參閱 Azure 良好架構架構中Microsoft成本優化 原則。

部署此案例

此案例的原始程式碼可在 GitHub 上取得。 您也可以在此 GitHub 存放庫中找到示範應用程式，如下圖所示。

下載此架構的 Visio 檔案。

必要條件

針對在線部署，您必須擁有現有的 Azure 帳戶。 如果您需要一個帳戶，請在開始之前建立 免費的 Azure 帳戶 。

部署至 Azure

1. 請確定您的 Azure 訂用帳戶資訊方便使用。

2. 從複製 workbench GitHub 存放庫開始：

   git clone https://github.com/Azure-Samples/aks-agic.git
   

3. 請遵循 README.md 檔案中提供的指示。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

• Paolo Salvatori |首席服務工程師

下一步

Azure Kubernetes Service

• 建立私人 Azure Kubernetes Service 叢集
• 多租使用者和叢集隔離的最佳做法
• Azure Kubernetes Service 中基本排程器功能的最佳做法 （AKS）
• 進階排程器功能的最佳做法
• 驗證和授權的最佳做法
• Azure Kubernetes Service (AKS) 中叢集安全性與升級的最佳做法
• Azure Kubernetes Service 中容器映射管理和安全性的最佳做法 （AKS）
• Azure Kubernetes Service (AKS) 中的網路連線和安全性最佳做法
• Azure Kubernetes Service 中記憶體和備份的最佳做法 （AKS）
• Azure Kubernetes 服務（AKS）中商務持續性和災害復原的最佳做法
• Azure Kubernetes Services （AKS） 第 2 天作業指南

Azure 應用程式閘道

• 應用程式閘道 中的 WebSocket 支援概觀
• 透過 PowerShell 使用應用程式閘道來設定端對端 SSL
• 應用程式閘道的運作方式

Azure 應用程式閘道 輸入控制器

• 什麼是應用程式閘道輸入控制器？
• 應用程式閘道 輸入控制器的檔
• 應用程式閘道 輸入控制器的註釋
• 具有 LetsEncrypt.org 的憑證發行
• 教學課程：針對具有新 應用程式閘道 實例的新 AKS 叢集啟用輸入控制器附加元件 （預覽）
• 教學課程：透過 Azure CLI 為現有 AKS 叢 應用程式閘道 集啟用 應用程式閘道 輸入控制器附加元件（預覽版）
• Helm 部署與 AKS 附加元件之間的差異

Azure 應用程式閘道 WAF

• 什麼是 Azure 應用程式閘道上的 Web 應用程式防火牆？
• Web 應用程式防火牆 CRS 規則群組和規則 (機器翻譯)
• 在 Azure 應用程式閘道上自訂 Web 應用程式防火牆 v2 的規則
• 快速入門：使用ARM範本在 應用程式閘道 上建立 Azure WAF v2
• Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies 資源類型
• 建立和使用應用程式閘道上的 Web 應用程式防火牆 v2 自訂規則
• az network application-gateway waf-policy Azure CLI 命令
• 使用 Azure CLI 啟用 Web 應用程式防火牆
• 使用 Azure PowerShell 設定每個月臺 WAF 原則
• 建立 應用程式閘道 的 Web 應用程式防火牆 原則

相關資源

架構指引

• Azure Kubernetes Service （AKS） 解決方案旅程圖
• AKS 叢集最佳做法
• Azure Kubernetes Services （AKS） 第 2 天作業指南
• 在邊緣計算選項中選擇 Kubernetes

參考架構

• Azure Kubernetes Service (AKS) 叢集的基準架構
• Azure Kubernetes Service 上的微服務架構 （AKS）
• 進階 Azure Kubernetes Service （AKS） 微服務架構
• 容器型工作負載的 CI/CD 管線