多租使用者的 Azure Kubernetes Service （AKS） 考慮

Azure Kubernetes Service （AKS） 藉由將作業額外負荷卸除至 Azure 雲端平台，簡化在 Azure 中部署受控 Kubernetes 叢集。 由於託管的 Kubernetes 服務，Azure 會處理重要的工作，例如健康情況監控和維護。 Azure 平台會管理 AKS 控制平面，您只需支付用於執行應用程式的 AKS 節點費用。

AKS 叢集可以在不同案例和方式中跨多個租用戶共用。 在某些情況下，不同的應用程式可以在相同的叢集中執行。 在其他情況下，相同應用程式的多個實例可以在相同的共用叢集中執行，每個租使用者各一個。 所有這些類型的共用通常會使用傘式字詞 多租用戶來描述。 Kubernetes 沒有使用者或租使用者的第一級概念。 不過，它提供數個功能來協助您管理不同的租用需求。

在本文中，我們會描述 AKS 的一些功能，這些功能在建置多租用戶系統時很有用。 如需 Kubernetes 多租使用者的一般指引和最佳做法，請參閱 Kubernetes 檔中的多租使用者 。

多租用戶類型

決定如何在多個租用戶之間共用 AKS 叢集的第一個步驟是評估您處置的模式和工具。 一般而言，Kubernetes 叢集中的多租用戶分為兩個主要類別，不過仍有許多變化。 Kubernetes 檔 說明多租使用者的兩個常見使用案例：多個小組和多個客戶。

多個小組

多租使用者的共同形式是在組織內的多個小組之間共用叢集。 每個小組都可以部署、監視及操作一或多個解決方案。 這些工作負載經常需要彼此通訊，並與位於相同叢集或其他裝載平臺的其他內部或外部應用程式通訊。

此外，這些工作負載需要與關係資料庫、NoSQL 存放庫或傳訊系統等服務通訊，這些系統裝載於相同叢集中，或在 Azure 上以 PaaS 服務身分執行。

在此案例中，小組成員通常會透過 kubectl 等工具直接存取 Kubernetes 資源。 或者，成員可以透過 GitOps 控制器間接存取，例如 Flux 和 Argo CD，或透過其他類型的發行自動化工具。

如需此案例的詳細資訊，請參閱 Kubernetes 檔中的多個小組 。

多個客戶

另一種常見的多租使用者形式經常涉及軟體即服務 （SaaS） 廠商。 或者，服務提供者會為其客戶執行多個工作負載實例，這些實例會被視為個別租使用者。 在此案例中，客戶沒有 AKS 叢集的直接存取權，但他們只能存取其應用程式。 此外，他們甚至不知道其應用程式在 Kubernetes 上執行。 成本優化通常很重要。 服務提供者會使用 Kubernetes 原則，例如 資源配額 和 網路原則，以確保工作負載彼此緊密隔離。

如需此案例的詳細資訊，請參閱 Kubernetes 檔中的多個客戶 。

隔離模型

根據 Kubernetes 檔，多租使用者 Kubernetes 叢集是由多個使用者和通常稱為 租使用者的工作負載共用。 此定義包含不同小組或部門在組織內共用的 Kubernetes 叢集。 它也包含由軟體即服務 （SaaS） 應用程式的個別客戶實例共用的叢集。

叢集多租使用者是管理許多單一租使用者專用叢集的替代方案。 多租使用者 Kubernetes 叢集的操作員必須彼此隔離租使用者。 此隔離可將遭入侵或惡意租使用者對叢集和其他租用戶的損害降到最低。

當數個使用者或小組與固定數目的節點共用同一個叢集時，有一個小組可能會使用超過其公平資源份額的問題。 資源配額 是系統管理員解決此問題的工具。

根據隔離所提供的安全性層級，我們可以區分軟式和硬式多租使用者。

• 軟式多租用戶適用於單一企業，其中租使用者是彼此信任的不同小組或部門。 在此案例中，隔離旨在保證工作負載完整性、跨不同內部使用者群組協調叢集資源，以及防範可能的安全性攻擊。
• 硬式多租用戶可用來描述異質租使用者彼此不信任的案例，通常是從安全性和資源分享的觀點來看。

當您打算建置多租使用者 Azure Kubernetes Service （AKS） 叢集時，您應該考慮 Kubernetes 所提供的資源隔離和多租用戶層：

• Cluster
• Namespace
• 節點集區或節點
• Pod
• 容器

此外，您應該考慮在多個租用戶之間共用不同資源的安全性影響。 例如，在相同節點上排程來自不同租使用者的 Pod 可能會減少叢集中所需的機器數目。 另一方面，您可能需要防止特定工作負載共置。 例如，您可能不允許組織外部不受信任的程式代碼在處理敏感性資訊的容器上執行。

雖然 Kubernetes 無法保證租使用者之間的完全安全隔離，但它確實提供可能足以用於特定使用案例的功能。 最佳做法是，您應該將每個租使用者及其 Kubernetes 資源分成其命名空間。 接著 ，您可以使用 Kubernetes 角色型存取控制 （RBAC） 和 網路原則 來強制執行租用戶隔離。 例如，下圖顯示在相同叢集上裝載相同應用程式多個實例的一般 SaaS 提供者模型，每個租使用者各一個實例。 每個應用程式都位於個別的命名空間中。

有數種方式可以使用 Azure Kubernetes Service （AKS） 來設計和建置多租用戶解決方案。 在基礎結構部署、網路拓撲和安全性方面，這些方法都有其本身的取捨。 這些方法會影響隔離等級、實作工作、操作複雜度和成本。 您可以根據需求，在控件和數據平面中套用租用戶隔離。

控制平面隔離

如果您在控制平面層級有隔離，則保證不同的租用戶無法存取或影響彼此的資源，例如 Pod 和服務。 此外，它們不會影響其他租使用者應用程式的效能。 如需詳細資訊，請參閱 Kubernetes 檔中的控制平面隔離 。 在控制平面層級實作隔離的最佳方式，是將每個租使用者的工作負載及其 Kubernetes 資源隔離成個別的命名空間。

根據 Kubernetes 檔，命名空間是一種抽象概念，用來支援單一叢集中資源群組的隔離。 命名空間可用來隔離共用 Kubernetes 叢集的租使用者工作負載：

• 命名空間可讓不同的租使用者工作負載存在於自己的虛擬工作區中，而不會有影響彼此工作的風險。 組織內的個別小組可以使用命名空間來彼此隔離專案，因為它們可以在不同命名空間中使用相同的資源名稱，而不會有名稱重疊的風險。
• RBAC 角色和角色系結 是命名空間範圍的資源，小組可用來限制租使用者使用者和進程，只在其命名空間中存取資源和服務。 不同的小組可以定義角色，以將許可權清單或功能群組在單一名稱下。 然後，他們會將這些角色指派給使用者帳戶和服務帳戶，以確保只有授權的身分識別可以存取指定命名空間中的資源。
• CPU 和記憶體的資源配額 是命名空間物件。 Teams 可以使用它們來確保共用相同叢集的工作負載會與系統資源耗用量緊密隔離。 這個方法可以確保每個在個別命名空間中執行的租使用者應用程式都有執行所需的資源，並避免 發生嘈雜的鄰近問題，這可能會影響其他共用相同叢集的租用戶應用程式。
• 網路原則 是小組可以採用的命名空間物件，可強制執行指定租使用者應用程式允許的網路流量。 您可以使用網路原則來隔離從網路觀點共用相同叢集的不同工作負載。
• 在不同命名空間中執行的小組應用程式可以使用不同的 服務帳戶來存取相同叢集、外部應用程式或受控服務內的資源。
• 使用命名空間來改善控制平面層級的效能。 如果共用叢集中的工作負載組織成多個命名空間，Kubernetes API 在執行作業時要搜尋的專案較少。 此組織可以降低對 API 伺服器的呼叫延遲，並增加控制平面的輸送量。

如需命名空間層級隔離的詳細資訊，請參閱 Kubernetes 檔中的下列資源：

• 命名空間
• 存取控制
• 配額

數據平面隔離

數據平面隔離可確保不同租使用者的Pod和工作負載彼此相隔離。 如需詳細資訊，請參閱 Kubernetes 檔中的數據平面隔離 。

網路隔離

在 Kubernetes 中執行現代微服務型應用程式時，最好要能控制能與彼此通訊的元件。 根據預設，AKS 叢集中的所有 Pod 都可以傳送和接收流量，而不受限制，包括共用相同叢集的其他應用程式。 若要改善安全性，您可以定義網路規則來控制流量。 網路原則是 Kubernetes 規格，可定義 Pod 之間通訊的存取原則。 您可以使用 網路原則 來隔離共用相同叢集之租使用者應用程式之間的通訊。

Azure Kubernetes Service （AKS） 提供兩種方式來實作網路原則：

1. Azure 已實作網路原則，稱為 Azure 網路原則。
2. Calico 網路原則是 Tigera 所建立的開放原始碼網路和網路安全性解決方案。

這兩個實作都使用Linux IPTable來強制執行指定的原則。 網路原則會轉譯成一組允許和不允許的IP組。 然後，這些配對會程式設計為IPTable篩選規則。 您只能搭配使用 Azure CNI 網路外掛程式所設定的 AKS 叢集使用 Azure 網路原則。 不過，Calico 網路原則同時 支援 Azure CNI 和 kubenet。 如需詳細資訊，請參閱 在 Azure Kubernetes Service 中使用網路原則保護 Pod 之間的流量。

如需詳細資訊，請參閱 Kubernetes 檔中的網路隔離 。

儲存體隔離

Azure 提供一組豐富的受控平臺即服務 （PaaS） 數據存放庫，例如 Azure SQL 資料庫 和 Azure Cosmos DB，以及其他記憶體服務，可讓您作為工作負載的永續性磁碟區。 在共用 AKS 叢集上執行的租使用者應用程式可以共用資料庫或檔案存放區，也可以使用專用的數據存放庫和記憶體資源。 如需在多租使用者案例中管理數據之不同策略和方法的詳細資訊，請參閱 多租使用者解決方案中儲存和數據的結構方法。

在 Azure Kubernetes Service 上執行的工作負載 （AKS） 也可以使用永續性磁碟區來儲存數據。 在 Azure 上，您可以將永續性磁碟區建立為由 Azure 儲存體 支援的 Kubernetes 資源。 您可以手動建立數據磁碟區，並將其直接指派給 Pod，或者您可以讓 AKS 使用 永續性磁碟區宣告自動建立它們。 AKS 提供內建記憶體類別，以建立由 Azure 磁碟、Azure 檔案儲存體 和 Azure NetApp Files 支援的永續性磁碟區。 如需詳細資訊，請參閱 Azure Kubernetes Service （AKS） 中應用程式的記憶體選項。 基於安全性和復原考慮，您應該避免透過 emptyDir 和 hostPath 在代理程式節點上使用本機記憶體。

當 AKS 內建記憶體類別 不適合一或多個租使用者時，您可以建置自定義 記憶體類別 來解決不同的租使用者需求。 這些需求包括磁碟區大小、記憶體 SKU、服務等級協定（SLA）、備份原則和定價層。

例如，您可以為每個租用戶設定自訂記憶體類別。 然後，您可以使用它，將標籤套用至在其命名空間中建立的任何永續性磁碟區，以向它們收取其成本。 如需此案例的詳細資訊，請參閱 在 Azure Kubernetes Service （AKS） 中使用 Azure 標籤。

如需詳細資訊，請參閱 Kubernetes 檔中的記憶體隔離 。

節點隔離

您可以將租使用者工作負載設定為在不同的代理程序節點上執行，以避免 Noisy Neighbor 問題 ，並降低資訊洩漏的風險。 在 AKS 中，您可以針對隔離、安全性、法規合規性和效能有嚴格需求的租使用者，建立個別的叢集，或只建立專用節點集區。

您可以使用 污點、 容忍、 節點標籤、 節點選取器，以及節點親和 性 來限制租使用者的 Pod 只在特定一組節點或節點集區上執行。

一般而言，AKS 會在各種層級提供工作負載隔離：

• 在核心層級，在共用代理程序節點上的輕量型虛擬機中執行租使用者工作負載，並使用以 Kata Containers 為基礎的 Pod 沙盒。
• 在實體層級上，藉由將租使用者應用程式裝載在專用叢集或節點集區上。
• 在硬體層級上，藉由在 Azure 專用主機上 執行租使用者工作負載，以確保代理程式節點 VM 執行專用實體機器。 硬體隔離可確保沒有其他虛擬機放在專用主機上，為租使用者工作負載提供額外的隔離層。

您可以結合這些技術。 例如，您可以在 Azure 專用主機群組中執行個別租使用者叢集和節點集區，以達到硬體層級的工作負載隔離和實體隔離。 您也可以建立支持聯邦資訊處理標準（FIPS）、機密 虛擬機器（CVM）或主機型加密的共用或個別租用戶節點集區。

節點隔離可讓您輕鬆地將一組節點或節點集區的成本與單一租用戶產生關聯並收取費用。 其與解決方案採用的租用模型嚴格相關。

如需詳細資訊，請參閱 Kubernetes 檔中的節點隔離 。

租用模型

Azure Kubernetes Service （AKS） 提供更多類型的節點隔離和租用模型。

自動化單一租使用者部署

在自動化的單一租使用者部署模型中，您會為每個租使用者部署一組專用的資源，如下列範例所示：

每個租使用者工作負載都會在專用的 AKS 叢集中執行，並存取一組不同的 Azure 資源。 一般而言，使用此模型建置的多租用戶解決方案會大量使用基礎結構即程序代碼（IaC）。 例如，Bicep、Azure Resource Manager、Terraform 或 Azure Resource Manager REST API 可協助起始及協調租使用者專用資源的隨選部署。 當您需要為每個客戶布建完全獨立的基礎結構時，您可以使用此方法。 規劃部署時，請考慮使用 部署戳記模式。

優點：

• 這種方法的主要優點是每個租使用者 AKS 叢集的 API 伺服器是分開的。 此方法可確保租用戶與安全性、網路和資源耗用量層級之間的完全隔離。 設法控制容器的攻擊者只能存取屬於單一租使用者的容器和磁碟區。 完全隔離租用模型對於某些具有高法規合規性負擔的客戶至關重要。
• 租使用者不太可能影響彼此的系統效能，這可讓您避免 Noisy Neighbor 問題。 此考慮包括針對 API 伺服器的流量。 API 伺服器是任何 Kubernetes 叢集中的共用重要元件。 針對 API 伺服器產生不受管制、大量流量的自定義控制器可能會導致叢集不穩定。 這種不穩定會導致要求失敗、逾時和 API 重試風暴。 運行 時間 SLA （服務等級協定） 功能可讓您相應放大 AKS 叢集的控制平面，以符合流量需求。 不過，在工作負載隔離方面，布建專用叢集可能是那些具有強大需求的客戶較佳的解決方案。
• 您可以逐步跨租使用者推出更新和變更，以降低全系統中斷的可能性。 Azure 成本可以輕鬆地向租用戶收費，因為單一租使用者會使用每個資源。

風險：

• 成本效益很低，因為每個租使用者都使用一組專用的資源。
• 進行中的維護可能會很耗時，因為它需要跨多個 AKS 叢集進行複寫，每個租使用者各一個。 請考慮將作業程式自動化，並逐步透過您的環境套用變更。 如果您也考慮其他跨部署作業，例如整個資產的報表和分析，這會有所説明。 同樣地，請確定您規劃如何跨多個部署查詢和操作數據。

完全多租使用者部署

在完全多租使用者部署中，單一應用程式會提供所有租使用者的要求，並共用所有 Azure 資源，包括 AKS 叢集。 在此內容中，您只有一組基礎結構可以部署、監視和維護。 所有租用戶都會使用資源，如下圖所示：

優點：

• 此模型很有吸引力，因為使用共用元件操作解決方案的成本較低。 使用此租用模型時，您可能需要部署較大的 AKS 叢集，並針對任何共用數據存放庫採用較高的 SKU，以維持所有租用戶資源所產生的流量，例如數據存放庫。

風險：

• 在此內容中，單一應用程式會處理所有租使用者的要求。 您應該設計和實作安全性措施，以防止租使用者大量呼叫應用程式。 這些呼叫可能會讓整個系統變慢，並影響所有租使用者。
• 如果流量配置檔具有高度變數，您應該設定 AKS 叢集自動調整程式來改變 Pod 和代理程式節點的數目。 將您的設定以系統資源使用量為基礎，例如 CPU 和記憶體。 或者，您可以根據自定義計量相應放大和相應放大Pod和叢集節點的數目。 例如，您可以探索使用 Kubernetes 事件驅動自動調整 （KEDA） 的外部傳訊系統擱置要求數目或計量。
• 請務必分隔每個租用戶的數據，並實作保護措施，以避免不同租使用者之間的數據外泄。
• 請務必 根據個別租用戶的實際使用量，追蹤 Azure 成本 並將其關聯至個別租使用者。 第三方解決方案，例如 kubecost，可協助您計算和細分不同小組和租使用者的成本。
• 單一部署可以更直接維護，因為您只需要更新一組 Azure 資源並維護單一應用程式。 不過，由於基礎結構或應用程式元件的任何變更都可能會影響整個客戶群，因此通常也會有風險。
• 您也應該考慮調整限制。 當您有一組共用的資源時，更有可能達到 Azure 資源規模限制。 為了避免達到資源配額限制，您可以考慮將租使用者分散到多個 Azure 訂用帳戶。

水準分割的部署

或者，您可以考慮水準分割多租使用者 Kubernetes 應用程式。 此方法包含跨所有租用戶共用一些解決方案元件，以及為個別租使用者部署專用資源。 例如，您可以建置單一多租使用者 Kubernetes 應用程式，然後為每個租使用者建立個別資料庫，如下圖所示：

優點：

• 水準分割的部署可協助您減輕 Noisy Neighbor 問題。 如果您發現 Kubernetes 應用程式上大部分的流量負載都是因為您可以針對每個租用戶個別部署的特定元件，請考慮這種方法。 例如，您的資料庫可能會吸收您系統的大部分負載，因為查詢負載很高。 如果單一租使用者將大量要求傳送至您的解決方案，資料庫效能可能會受到負面影響，但其他租用戶的資料庫（和應用程式層等共用元件）仍不會受到影響。

風險：

• 使用水準分割的部署，您仍然需要考慮元件的自動化部署和管理，特別是單一租使用者所使用的元件。
• 基於內部原則或合規性原因，此模型可能無法提供無法與其他租使用者共用資源的客戶所需的隔離等級。

垂直分割的部署

您可以使用混合式模型，將租使用者垂直分割到多個 AKS 叢集或節點集區，來利用單一租使用者和完全多租使用者模型的優點。 此方法提供下列優點，比前兩個租用模型：

• 您可以使用單一租使用者和多租使用者部署的組合。 例如，您可以讓大部分的客戶在多租使用者基礎結構上共用 AKS 叢集和資料庫。 不過，您也可以為需要更高效能和隔離的客戶部署單一租用戶基礎結構。
• 您可以將租使用者部署到多個區域 AKS 叢集，可能有不同的設定。 當您的租使用者分散到不同的地理位置時，這項技術最有效。

您可以實作此租用模型的不同變化。 例如，您可以選擇以不同的成本提供多租用戶解決方案與不同層級的功能。 您的定價模型可以提供多個 SKU，每個 SKU 在資源分享、效能、網路和數據隔離方面提供累加層級的效能和隔離。 請考慮下列層級：

• 基本層：租使用者要求是由與其他租用戶共用的單一多租使用者 Kubernetes 應用程式提供服務。 數據會儲存在所有基本層租用戶共用的一或多個資料庫中。
• 標準層：租使用者要求是由在個別命名空間中執行的專用 Kubernetes 應用程式提供服務，其提供安全性、網路功能、資源耗用量方面的隔離界限。 所有租用戶的應用程式，每個租使用者一個，與其他標準層客戶共用相同的 AKS 叢集和節點集區。
• 進階層：租使用者應用程式會在專用節點集區或 AKS 叢集中執行，以確保更高的服務等級協定、更好的效能，以及更高的隔離程度。 此層可以根據用來裝載租使用者應用程式的代理程序節點數目和 SKU，提供彈性的成本模型。 您可以使用 Pod沙盒 作為替代解決方案，以使用專用叢集或節點集區來隔離不同的租使用者工作負載。

下圖顯示租使用者 A 和 B 在共用 AKS 叢集上執行的案例，而租使用者 C 則在不同的 AKS 叢集上執行。

同樣地，下圖顯示租使用者 A 和 B 在同一個節點集區上執行的案例，而租使用者 C 則會在專用節點集區上執行。

此模型也可以為不同層級提供不同的服務等級協定。 例如，基本層可以提供99.9%運行時間、標準層可以提供99.95%的運行時間，而進階層可以提供99.99%的運行時間。 使用啟用更高可用性目標的服務和功能，即可實作較高的服務等級協定（SLA）。

優點：

• 由於您仍在共用基礎結構，因此您仍然可以獲得共用多租使用者部署的一些成本效益。 您可以部署跨多個基本層和標準層租使用者應用程式共用的叢集和節點集區，這些應用程式會針對代理程序節點使用更便宜的 VM 大小。 這種方法可保證更好的密度和節省成本。 針對進階層客戶，您可以部署 VM 大小較高的 AKS 叢集和節點集區，並以較高的價格部署 Pod 複本和節點數目上限。
• 您可以在專用的系統模式節點集區中執行系統服務，例如 CoreDNS、Konnectivity 或 Azure 應用程式閘道 輸入控制器。 您可以使用污點、容忍、節點標籤、節點選取器和節點親和性，在一或多個使用者模式節點集區上執行租用戶應用程式。
• 您可以使用 污點、 容忍、 節點標籤、 節點選取器，以及節點親和 性 來執行共享資源。 例如，您可以在專用節點集區上擁有輸入控制器或傳訊系統，其具有特定的 VM 大小、自動調整程式設定和可用性區域支援。

風險：

• 您必須設計 Kubernetes 應用程式，以支援多租使用者和單一租使用者部署。
• 如果您打算允許在基礎結構之間進行移轉，您必須考慮如何將客戶從多租使用者部署移轉至自己的單一租使用者部署。
• 您需要一致的策略和單一窗格（一個觀點）來監視和管理更多 AKS 叢集。

自動調整

若要跟上租使用者應用程式所產生的流量需求，您可以啟用 叢集自動調整程式 來調整 Azure Kubernetes Service （AKS） 的代理程序節點。 自動調整可協助系統在下列情況下保持回應：

• 流量負載會在一年中的特定工作時間或期間增加。
• 租用戶或共用大量負載會部署到叢集。
• 由於區域性中斷，代理程序節點變得無法使用。

當您啟用節點集區的自動調整時，您會根據預期的工作負載大小指定最小和最大數目的節點。 藉由設定節點數目上限，您可以確保叢集中所有租使用者Pod有足夠的空間，而不論其執行中的命名空間為何。

當流量增加時，叢集自動調整會增加新的代理程序節點，以避免 Pod 進入擱置狀態，因為 CPU 和記憶體資源短缺。

同樣地，當負載減少時，叢集自動調整會根據指定的界限減少節點集區中的代理程序節點數目，這有助於降低您的營運成本。

您可以使用Pod自動調整，根據資源需求自動調整Pod。 水準 Pod 自動調整程式 （HPA） 會根據 CPU/記憶體使用率或自定義計量，自動調整 Pod 複本的數目。 使用 Kubernetes 事件驅動自動調整 （KEDA），您可以根據外部系統的事件數目，例如租使用者應用程式所使用的 Azure 事件中樞 或 Azure 服務匯流排，來推動 Kubernetes 中任何容器的調整。

維護

若要降低在叢集或節點集區升級期間可能會影響租使用者應用程式的停機時間風險，請排程 AKS 計劃性維護 在離峰時段進行。 計劃性維護可讓您排程每周維護時段，以更新執行租使用者應用程式和節點集區之 AKS 叢集的控制平面，以將工作負載影響降至最低。 您可以指定特定日期或時間範圍，在叢集上排程一或多個每周維護時段。 所有維護作業都會在排程的期間進行。

安全性

叢集存取

當您在組織內的多個小組之間共用 AKS 叢集時，您必須實 作最低許可權 原則，以隔離不同的租使用者彼此。 特別是，當您使用 kubectl、Helm、Flux、Argo CD 或其他類型的工具時，您必須確定使用者只能存取其 Kubernetes 命名空間和資源。

如需使用 AKS 進行驗證和授權的詳細資訊，請參閱下列文章：

• Azure Kubernetes Service (AKS) 的存取與身分識別選項
• AKS 管理的 Microsoft Entra 整合
• 使用 Kubernetes 角色型訪問控制來控制叢集資源的存取，並在 Azure Kubernetes Service 中Microsoft Entra 身分識別

工作負載身分識別

如果您在單一 AKS 叢集上裝載多個租使用者應用程式，且每個應用程式都位於不同的命名空間中，則每個工作負載都應該使用不同的 Kubernetes 服務帳戶 和認證來存取下游 Azure 服務。 Kubernetes 的其中一個主要使用者類型是「服務帳戶」。 Kubernetes API 會保存和管理服務帳戶。 服務帳戶認證會儲存為 Kubernetes 秘密，讓授權的 Pod 用來與 API 伺服器通訊。 大部分的 API 要求會為服務帳戶或一般使用者帳戶提供驗證權杖。

部署至 AKS 叢集的租使用者工作負載可以使用 Microsoft Entra 應用程式認證來存取 Microsoft 受專案識別碼保護的資源，例如 Azure 金鑰保存庫 和 Microsoft Graph。 適用於 Kubernetes 的 Microsoft Entra 工作負載 ID 會與 Kubernetes 原生功能整合，以與任何外部身分識別提供者同盟。

Pod 沙箱

AKS 包含稱為 Pod 沙盒 的機制，可在容器應用程式與容器主機的共用核心和計算資源之間提供隔離界限，例如 CPU、記憶體和網路功能。 Pod 沙盒可補充其他安全性措施或數據保護控制，以協助租使用者工作負載保護敏感性資訊，並符合法規、產業或治理合規性需求，例如支付卡產業數據安全性標準 （PCI DSS）、國際標準化組織 （ISO） 27001，以及健康保險可移植性和責任法案 （HIPAA）。

在不同的叢集或節點集區上部署應用程式，可讓您強烈隔離不同小組或客戶的租使用者工作負載。 使用多個叢集和節點集區可能適用於許多組織和 SaaS 解決方案的隔離需求，但在某些情況下，具有共用 VM 節點集區的單一叢集更有效率，例如，當您在同一節點上執行不受信任且受信任的 Pod，或共置相同節點上的 DaemonSet 和特殊許可權容器，以加快本機通訊和功能群組的速度。 Pod 沙盒 可協助您在相同的叢集節點上強式隔離租使用者應用程式，而不需要在不同的叢集或節點集區中執行這些工作負載。 其他方法會要求您重新編譯程式代碼或造成其他相容性問題，但 AKS 中的 Pod 沙箱可以在增強式安全性 VM 界限內執行未修改的任何容器。

AKS 上的 Pod 沙箱是以適用於 AKS 堆疊的 Azure Linux 容器主機上執行的 Kata 容器為基礎，以提供硬體強制執行的隔離。 AKS 上的 Kata 容器是以安全性強化的 Azure Hypervisor 為基礎所建置。 每個 Pod 的隔離是透過巢狀輕量型 Kata VM 來達成，該 VM 會利用父 VM 節點中的資源。 在此模型中，每個 Kata Pod 都會在巢狀 Kata 客體 VM 中取得自己的核心。 此模型可讓您將許多 Kata 容器放在單一客體 VM 中，同時繼續在父 VM 中執行容器。 此模型會在共用 AKS 叢集中提供強式隔離界限。

如需詳細資訊，請參閱

• 使用 Azure Kubernetes Service 進行 Pod 沙盒處理 （AKS）
• 支援適用於Pod沙盒的AKS上的Kata VM隔離容器

Azure 專用主機

Azure 專用主機 是一項服務，提供專用於單一 Azure 訂用帳戶的實體伺服器，並在實體伺服器層級提供硬體隔離。 這些專用主機可以在區域、可用性區域和容錯網域內布建，而您可以將 VM 直接放入已布建的主機中。

您可以使用 Azure 專用主機搭配 AKS 來達成數個優點，包括下列各項：

• 硬體隔離可確保沒有其他 VM 放在專用主機上，這會為租使用者工作負載提供額外的隔離層。 專用主機會部署在相同的數據中心，並與其他非隔離主機共用相同的網路和基礎記憶體基礎結構。

• Azure 專用主機可控制由 Azure 平臺起始的維護事件。 您可以選擇維護期間，以減少對服務的影響，並協助確保租使用者工作負載的可用性和隱私權。

Azure 專用主機可協助 SaaS 提供者確保租使用者應用程式符合法規、產業和治理合規性需求，以保護敏感性資訊。 如需詳細資訊，請參閱 將 Azure 專用主機新增至 Azure Kubernetes Service （AKS） 叢集。

機密虛擬機器

您可以使用機密 虛擬機器 （CVM） 將一或多個節點集區新增至 AKS 叢集，以解決租用戶的嚴格隔離、隱私權和安全性需求。 CVM 使用硬體型 信任執行環境 （TEE） 。 AMD Secure Encrypted Virtualization - 安全巢狀分頁 （SEV-SNP） 機密 VM 拒絕 Hypervisor 和其他主機管理程式代碼對 VM 記憶體和狀態的存取，為操作員存取新增深度防護層。 如需詳細資訊，請參閱 在 AKS 叢集中使用 CVM。

聯邦資訊程式標準 （FIPS）

FIPS 140-3 是美國政府標準，定義資訊技術產品和系統中密碼編譯模組的最低安全性需求。 藉由啟用 AKS 節點集區的 FIPS 合規性，您可以增強租使用者工作負載的隔離、隱私權和安全性。 FIPS 合規性可確保使用已驗證的密碼編譯模組進行加密、哈希和其他安全性相關作業。 透過啟用 FIPS 的 AKS 節點集區，您可以採用強固的密碼編譯演算法和機制，以符合法規和產業合規性需求。 Azure 提供如何為 AKS 節點集區啟用 FIPS 的檔，讓您能夠強化多租使用者 AKS 環境的安全性狀態。 如需詳細資訊，請參閱 啟用 AKS 節點集區的 FIPS。

攜帶您自己的金鑰 （BYOK） 與 Azure 磁碟

Azure 儲存體 加密待用儲存體帳戶中的所有數據，包括 AKS 叢集的 OS 和數據磁碟。 根據預設，資料是以使用 Microsoft 管理的金鑰加密。 若要進一步控制加密金鑰，您可以提供客戶管理的金鑰，以用於 AKS 叢集的作業系統和數據磁碟的其餘部分進行加密。 如需詳細資訊，請參閱

• BYOK 與 AKS 中的 Azure 磁碟
• Azure 磁碟儲存體的伺服器端加密

啟用主機型加密

AKS 上的主機式加密 可進一步加強租使用者工作負載隔離、隱私權和安全性。 當您啟用主機型加密時，AKS 會加密基礎主計算機上待用的數據，協助確保敏感性租用戶資訊受到保護，免於未經授權的存取。 當您啟用端對端加密時，暫存磁碟和暫時性 OS 磁碟會使用平台代控金鑰進行待用加密。

在 AKS 中，OS 和數據磁碟預設會使用伺服器端加密搭配平臺管理的密鑰。 這些磁碟的快取會使用平台代控金鑰進行待用加密。 您可以使用信封加密來指定自己的 密鑰加密金鑰（KEK）， 以加密 數據保護密鑰（DEK）， 也稱為 包裝。 OS 和資料磁碟的快取也會透過 您指定的 BYOK 加密。

主機型加密為多租用戶環境增添了一層安全性。 OS 和數據磁碟快取中的每個租用戶數據都會使用客戶管理的或平臺管理的密鑰進行待用加密，視選取的磁碟加密類型而定。 如需詳細資訊，請參閱

• AKS 上的主機型加密
• BYOK 與 AKS 中的 Azure 磁碟
• Azure 磁碟儲存體的伺服器端加密

網路

限制對 API 伺服器的網路存取

在 Kubernetes 中，API 伺服器會收到要求以在叢集中執行動作，例如建立資源或調整節點數目。 在組織內的多個小組之間共用 AKS 叢集時，請使用下列其中一個解決方案來保護控制平面的存取權。

私人 AKS 叢集

藉由使用私人 AKS 叢集，您可以確定 API 伺服器與節點集區之間的網路流量會保留在虛擬網路內。 在私人 AKS 叢集中，控制平面或 API 伺服器具有只能透過 Azure 私人端點存取 的內部 IP 位址，該端點位於 AKS 叢集的相同虛擬網路中。 同樣地，相同虛擬網路中的任何虛擬機都可以透過私人端點私下與控制平面通訊。 如需詳細資訊，請參閱建立私人 Azure Kubernetes Service 叢集。

授權的IP

改善叢集安全性並將攻擊降到最低的第二個選項是使用 授權的IP。 此方法會將公用 AKS 叢集的控制平面存取限制為已知的因特網通訊協定 （IP） 位址清單和無類別網域間路由 （CIDR）。 當您使用授權的IP時，它們仍會公開，但存取僅限於一組IP範圍。 如需詳細資訊，請參閱 使用 Azure Kubernetes Service （AKS） 中授權的 IP 位址範圍保護對 API 伺服器的存取。

Private Link 整合

Azure Private Link Service （PLS） 是一個基礎結構元件，可讓應用程式透過虛擬網路中定義的 Azure 私人端點 （PE） 私下連線到服務，並連線到 Azure Load Balancer （ALB） 實例的前端 IP 組態。 使用 Azure Private Link，服務提供者可以安全地將其服務提供給其租用戶，這些租使用者可以從 Azure 或內部部署連線，而不需要數據外泄風險。

您可以使用 Azure Private Link 服務整合 ，以安全的方式為租使用者提供其 AKS 裝載工作負載的私人連線能力，而不需要在公用因特網上公開任何公用端點。

如需如何為 Azure 裝載的多租使用者解決方案設定 Private Link 的一般指引，請參閱 多租使用者和 Azure Private Link。

反向 Proxy

反向 Proxy 是負載平衡器和 API 閘道，通常用於租使用者應用程式前方來保護、篩選和分派傳入要求。 熱門的反向 Proxy 支援負載平衡、SSL 終止和第 7 層路由等功能。 反向 Proxy 通常會實作，以協助提升安全性、效能和可靠性。 Kubernetes 的熱門反向 Proxy 包含下列實作：

• NGINX 輸入控制器 是支援進階功能的常用反向 Proxy 伺服器，例如負載平衡、SSL 終止和第 7 層路由。
• Traefik Kubernetes 輸入提供者 是 Kubernetes 輸入控制器，可藉由支援輸入規格來管理叢集服務的存取權。
• HAProxy Kubernetes 輸入控制器 是 Kubernetes 的另一個反向 Proxy，其支持標準功能，例如 TLS 終止、URL 路徑型路由等等。
• Azure 應用程式閘道 輸入控制器 （AGIC） 是 Kubernetes 應用程式，可讓 Azure Kubernetes Service （AKS） 客戶利用 Azure 的原生 應用程式閘道 L7 負載平衡器，將租使用者應用程式公開至公用因特網，或內部公開至虛擬網路中執行的其他系統。

使用 AKS 裝載的反向 Proxy 來保護及處理多個租使用者應用程式的連入要求時，請考慮下列建議：

• 在設定為使用具有高網路頻寬和 加速網路的 VM 大小的專用節點集區上裝載反向 Proxy。
• 設定裝載反向 Proxy 以進行自動調整的節點集區。
• 若要避免租使用者應用程式的延遲和逾時增加，請定義自動調整原則，讓輸入控制器 Pod 的數目可以立即展開並收縮，以符合流量波動。
• 請考慮將連入流量分區化至租使用者應用程式的多個輸入控制器實例，以增加延展性和隔離層級。

使用 Azure 應用程式閘道 輸入控制器 （AGIC）時，請考慮實作下列最佳做法：

• 設定輸入控制器用於自動調整的 應用程式閘道。 啟用自動調整后，應用程式閘道 和 WAF v2 SKU 會根據應用程式流量需求相應放大或縮小。 此模式為您的應用程式提供更好的彈性，並且不需要猜測應用程式閘道大小或執行個體計數。 此模式也可讓您節省成本，因為不需要閘道在預期的最大流量負載的尖峰布建容量上執行。 您必須指定實例計數下限（以及選擇性上限）。
• 當租使用者應用程式數目超過最大網站數量時，請考慮部署多個 應用程式閘道 輸入控制器 （AGIC）的實例，每個實例都與個別的 應用程式閘道 相關聯。 假設每個租使用者應用程式在專用命名空間中執行，請使用多個命名空間支援，將租使用者應用程式分散到 應用程式閘道 輸入控制器 （AGIC） 的更多實例。

與 Azure Front Door 整合

Azure Front Door 是全域第 7 層負載平衡器，Microsoft的新式雲端內容傳遞網路 （CDN）提供全球使用者與 Web 應用程式之間的快速、可靠且安全的存取。 Azure Front Door 支援要求加速、SSL 終止、回應快取、邊緣 WAF、URL 型路由、重寫和重新導向等功能，您可以在將 AKS 裝載的多租使用者應用程式公開至公用因特網時加以利用。

例如，您可能想要使用 AKS 裝載的多租使用者應用程式，為所有客戶的要求提供服務。 在此內容中，您可以使用 Azure Front Door 來管理多個自定義網域，每個租使用者各一個。 您可以在邊緣終止 SSL 連線，並將所有流量路由傳送至以單一主機名設定的 AKS 裝載多租使用者應用程式。

您可以設定 Azure Front Door 來修改 要求來源主機標頭 ，以符合後端應用程式的功能變數名稱。 用戶端所傳送的原始 Host 標頭會透過 X-Forwarded-Host 標頭傳播，多租使用者應用程式的程式代碼可以使用這項資訊，將 連入要求對應至正確的租使用者。

Azure Front Door 上的 Azure Web 應用程式防火牆 （WAF）可為 Web 應用程式提供集中式保護。 您可以使用 Azure WAF 來防禦 AKS 裝載的租使用者應用程式，這些應用程式會公開因特網上的公用端點免於遭受惡意攻擊。

您可以使用 Azure Private Link 服務，透過內部負載平衡器來源，將 Azure Front Door Premium 設定為私下連線到 AKS 叢集上執行的一或多個租用戶應用程式。 如需詳細資訊，請參閱 使用 Private Link 將 Azure Front Door Premium 連線到內部負載平衡器來源。

輸出連線

當 AKS 裝載的應用程式連線到大量資料庫或外部服務時，叢集可能會面臨 SNAT 埠耗盡的風險。 SNAT 埠 會產生唯一標識碼，用來維護由在相同計算資源集合上執行的應用程式所起始的不同流程。 藉由在共用 Azure Kubernetes Service （AKS） 叢集上執行數個租使用者應用程式，您可能會進行大量的輸出呼叫，這可能會導致 SNAT 埠耗盡。 AKS 叢集可以透過三種不同的方式處理輸出連線：

• Azure 公用負載平衡器：根據預設，AKS 會布建要設定及用於輸出連線的標準 SKU Load Balancer。 不過，如果不允許公用IP，或輸出需要其他躍點，預設設定可能無法符合所有案例的需求。 根據預設，公用 Load Balancer 會使用輸出規則所使用的預設公用 IP 位址來建立。 輸出規則可讓您明確定義公用標準負載平衡器的來源網路位址轉換 （SNAT）。 此設定可讓您使用負載平衡器的公用 IP，以為您的後端執行個體提供輸出網際網路連線能力。 必要時，若要避免 SNAT 埠耗盡，您可以設定公用負載平衡器的輸出規則，以使用其他公用 IP 位址。 如需詳細資訊，請參閱 使用負載平衡器的前端IP位址透過輸出規則輸出。
• Azure NAT 閘道：您可以設定 AKS 叢集，以使用 Azure NAT 閘道來路由來自租使用者應用程式的輸出流量。 NAT 閘道允許每個公用IP位址最多64,512個輸出UDP和TCP流量流動，最多16個IP位址。 若要避免使用 NAT 閘道處理 AKS 叢集的輸出連線時 SNAT 連接埠耗盡的風險，您可以將更多公用 IP 位址或 公用 IP 位址前綴 關聯至閘道。 如需詳細資訊，請參閱 多租使用者的 Azure NAT 閘道考慮。
• 使用者定義的路由 （UDR）：您可以自定義 AKS 叢集的輸出路由以支援自定義網路案例，例如不允許公用 IP，並要求叢集位於網路虛擬設備 （NVA） 後方。 當您設定 使用者定義路由的叢集時，AKS 不會自動設定輸出路徑。 輸出設定須由您完成。 例如，您會透過 Azure 防火牆 路由傳送輸出流量。 AKS 叢集必須部署至現有的虛擬網路，且子網先前已設定。 當您不使用標準負載平衡器 （SLB） 架構時，必須建立明確的輸出。 因此，此架構需要明確地將輸出流量傳送至設備，例如防火牆、網關或 Proxy。 或者，架構可讓指派給標準負載平衡器或設備的公用IP來完成網路位址轉換（NAT）。

監視

您可以使用 Azure 監視器 和 Container Insights 來監視在共用 AKS 叢集上執行的租使用者應用程式，以及計算個別命名空間的成本明細。 Azure 監視器可讓您監視 Azure Kubernetes Service （AKS） 的健康情況和效能。 其中包含記錄和計量的收集、遙測分析和所收集數據的視覺效果，以識別趨勢，以及設定警示以主動通知您重大問題。 您可以啟用 容器深入解析 ，以擴充此監視。

您也可以採用開放原始碼工具，例如 Prometheus 和 Grafana，供社群廣泛用於 Kubernetes 監視。 或者，您可以採用其他第三方工具來監視和可觀察性。

成本

成本控管是實作原則以控制成本的持續程式。 在 Kubernetes 內容中，組織有數種方式可以控制及優化成本。 其中包括原生 Kubernetes 工具，可管理和控管資源使用量和耗用量，以及主動監視和優化基礎結構。 計算每一租使用者成本時，您應該考慮與租使用者應用程式使用之任何資源相關聯的成本。 您遵循以向租使用者收取費用的方法取決於您解決方案採用的租用模型。 下列租用模型會進一步說明詳細數據：

• 完全多租使用者：當單一多租使用者應用程式提供所有租使用者要求時，您必須負責追蹤每個租使用者所產生的資源耗用量和要求號碼。 然後，您就會向您的客戶收取費用。
• 專用叢集：當叢集專用於單一租使用者時，可以輕鬆地向客戶收取 Azure 資源的成本。 總擁有成本取決於許多因素，包括虛擬機的數目和大小、網路成本，因為網路流量、公用IP位址、負載平衡器、記憶體服務，例如租用戶解決方案所使用的受控磁碟或 Azure 檔案等等。 您可以標記 AKS 叢集及其節點資源群組中的資源，以利進行成本收費作業。 如需詳細資訊，請參閱 將標籤新增至叢集。
• 專用節點集區：您可以將 Azure 標籤套用至單一租使用者專用的新或現有節點集區。 套用至節點集區的標籤會套用至節點集區內的每個節點，並透過升級來保存。 標籤也會套用至於向外延展作業期間新增至節點集區的新節點。 新增標籤有助於處理原則追蹤或成本收費等工作。 如需詳細資訊，請參閱 將標籤新增至節點集區。
• 其他資源：您可以使用標籤將專用資源的成本與指定的租用戶產生關聯。 特別是，您可以使用 Kubernetes 指令清單標記公用 IP、檔案和磁碟。 以這種方式設定的標籤會維護 Kubernetes 值，即使您稍後使用其他方法更新它們也一樣。 透過 Kubernetes 移除公用 IP、檔案或磁碟時，會移除 Kubernetes 所設定的任何標籤。 Kubernetes 未追蹤之資源上的標籤仍不會受到影響。 如需詳細資訊，請參閱 使用 Kubernetes 新增標籤。

您可以使用 KubeCost 等開放原始碼工具來監視和管理 AKS 叢集成本。 成本配置的範圍可設定為部署、服務、標籤、Pod 和命名空間，這可讓您彈性地向叢集使用者退款或回報使用者。 如需詳細資訊，請參閱 使用 Kubecost 進行成本控管。

如需多租使用者應用程式的測量、配置和優化成本的詳細資訊，請參閱 多租用戶解決方案中成本管理和配置架構方法。 如需成本優化的一般指引，請參閱 Azure 架構完善的架構文章： 成本優化支柱概觀

參與者

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

主體作者：

• Paolo Salvatori |適用於 Azure 的主要客戶工程師 FastTrack

其他投稿人：

• John Downs |適用於 Azure 的主要客戶工程師 FastTrack
• Ed Price |資深內容項目經理
• 阿森·弗拉基米爾斯基 | 適用於 Azure 的主要客戶工程師 FastTrack
• Bohdan Cherchyk |適用於 Azure 的 FastTrack 資深客戶工程師

下一步

檢閱 多租使用者解決方案架構設計人員和開發人員的資源。