編輯

共用方式為

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

Azure
Azure Kubernetes Service (AKS)

Azure Kubernetes Service （AKS） 藉由將作業額外負荷卸除至 Azure 雲端平臺，簡化在 Azure 中部署受控 Kubernetes 叢集。 因為 AKS 是託管的 Kubernetes 服務，Azure 會處理健康情況監視和維護和控制平面等重要工作。

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

本文說明當您建置多租用戶系統時，可以使用的AKS部分功能。 如需 Kubernetes 多租使用者的一般指引和最佳做法，請參閱 Kubernetes 檔中的 多租使用者。

多租用戶類型

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

多個小組

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

此外，這些工作負載需要與服務通訊，例如關係資料庫、NoSQL 存放庫或傳訊系統，這些系統裝載於相同叢集中，或以平臺即服務的形式在 Azure 上執行。

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

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

多個客戶

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

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

隔離模型

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

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

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

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

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

當您計劃建置多租使用者 AKS 叢集時，您應該考慮 kubernetes 所提供的資源隔離和多租用戶層，包括：

  • 簇
  • Namespace
  • 節點集區或節點
  • 莢
  • 容器

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

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

圖表，顯示 SaaS 提供者模型，該模型裝載相同叢集上相同應用程式的多個實例。

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

控制平面隔離

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

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

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

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

數據平面隔離

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

網路隔離

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

AKS 提供兩種方式來實作網路原則：

  • Azure 已實作網路原則，稱為 Azure 網路原則。
  • Calico 網路原則 是由 tigera 所建立的開放原始碼網路和網路安全解決方案。

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

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

記憶體隔離

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

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

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

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

如需詳細資訊，請參閱 Kubernetes 檔中 儲存器隔離。

節點隔離

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

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

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

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

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

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

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

租用模型

AKS 提供更多類型的節點隔離和租用模型。

自動化單一租使用者部署

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

顯示三個租用戶的圖表，每個租使用者都有個別的部署。

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

權益：

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

風險：

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

完全多租使用者部署

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

顯示三個租使用者全都使用單一共用部署的圖表。

權益：

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

風險：

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

水準分割的部署

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

顯示三個租用戶的圖表。每個都會使用專用資料庫和單一共用 Kubernetes 應用程式。

權益：

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

風險：

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

垂直分割的部署

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

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

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

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

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

顯示三個租用戶的圖表。租使用者 A 和 B 共用 AKS 叢集。租使用者 C 具有專用的 AKS 叢集。

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

顯示三個租用戶的圖表。租使用者 A 和 B 共用節點集區。租使用者 C 具有專用節點集區。

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

權益：

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

風險：

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

自動調整

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

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

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

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

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

您可以使用Pod自動調整，根據資源需求自動調整Pod。 HorizontalPodAutoscaler 會根據 CPU 或記憶體使用率或自定義計量自動調整 Pod 複本數目。 藉由使用 KEDA，您可以根據來自外部系統的事件數目，例如 Azure 事件中樞 或 Azure 服務總線，來推動 Kubernetes 中任何容器的調整。

垂直 Pod 自動調整程式 （VPA） 可為 Pod 提供有效率的資源管理。 藉由調整配置給 Pod 的 CPU 和記憶體，VPA 可協助您減少執行租使用者應用程式所需的節點數目。 擁有較少的節點可降低總擁有成本，並協助您避免嘈雜的鄰近問題。

將 容量保留群組 指派給節點集區，為不同的租使用者提供更好的資源配置和隔離。

保養

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

安全

下列各節說明使用 AKS 的多租使用者解決方案的安全性最佳做法。

叢集存取

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

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

工作負載身分識別

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

部署至 AKS 叢集的租使用者工作負載可以使用 Microsoft Entra 應用程式認證來存取Microsoft受專案標識碼保護的資源，例如 Azure Key Vault 和 Microsoft Graph。 Microsoft Kubernetes 的 Entra Workload 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 為基礎所建置。 其可透過巢狀輕量型 Kata VM 來達到每個 Pod 的隔離，以利用父 VM 節點的資源。 在此模型中，每個 Kata Pod 都會在巢狀 Kata 客體 VM 中取得自己的核心。 使用此模型，將許多 Kata 容器放在單一客體 VM 中，同時繼續在父 VM 中執行容器。 此模型會在共用 AKS 叢集中提供強式隔離界限。

如需詳細資訊，請參閱：

  • 使用 AKS Pod 沙盒
  • 適用於 Pod 沙盒化 AKS 上的 Kata VM 隔離容器 支援

Azure 專用主機

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

搭配 AKS 使用 Azure 專用主機有數個優點，包括：

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

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

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

卡彭特

Karpenter 是針對 Kubernetes 建置的開放原始碼節點生命週期管理專案。 將 Karpenter 新增至 Kubernetes 叢集可以提升在該叢集上執行工作負載的效率與成本。 Karpenter 會監看 Kubernetes 排程器標示為不可排程的 Pod。 它也會動態布建和管理可符合 Pod 需求的節點。

Karpenter 可針對受控叢集中的節點布建和工作負載放置提供更細緻的控制。 此控制項可藉由優化資源配置、確保每個租使用者應用程式之間的隔離，以及降低營運成本來改善多租使用者。 當您在 AKS 上建置多租使用者解決方案時，Karpenter 提供實用的功能，協助您管理不同的應用程式需求以支援不同的租使用者。 例如，您可能需要某些租使用者的應用程式在 GPU 優化節點集區上執行，而其他應用程式則需要在記憶體優化節點集區上執行。 如果您的應用程式需要低延遲的記憶體，您可以使用 Karpenter 來指出 Pod 需要在特定可用性區域中執行的節點，以便您可以共置記憶體和應用層。

AKS 可透過 Karpenter 在 AKS 叢集上啟用節點自動布建。 大部分的用戶都應該使用節點自動布建模式來啟用 Karpenter 作為受控附加元件。 如需詳細資訊，請參閱 節點自動布建。 如果您需要更進階的自定義，您可以選擇自我裝載 Karpenter。 如需詳細資訊，請參閱 AKS Karpenter 提供者。

機密 VM

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

聯邦資訊程式標準 （FIPS）

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

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

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

主機型加密

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

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

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

聯網

下列各節說明使用 AKS 的多租使用者解決方案網路最佳做法。

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

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

私人 AKS 叢集

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

授權的IP位址範圍

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

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

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

如需如何為 Azure 裝載的多租使用者解決方案設定 Private Link 的詳細資訊，請參閱 多租使用者和 Private Link。

反向 Proxy

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

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

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

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

  • 設定輸入控制器用於 自動調整的應用程式閘道 。 啟用自動調整后，應用程式閘道和 Web 應用程式防火牆 （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 和 AKS 如何連線。

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

Azure Web 應用程式防火牆，在 Azure Front Door 上，為 Web 應用程式提供集中式保護。 Azure Web 應用程式防火牆可協助您保護 AKS 裝載的租使用者應用程式，這些應用程式會公開因特網上的公用端點不受惡意攻擊。

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

輸出連線

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

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

監測

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

您也可以採用開放原始碼工具，例如 Prometheus 和 Grafana，其廣泛使用於 Kubernetes 監視。 或者，您可以採用其他非Microsoft工具來監視和可觀察性。

成本

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

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

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

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

統轄

當多個租用戶共用相同的基礎結構時，管理數據隱私權、合規性和法規需求可能會變得複雜。 您需要實作強式安全性措施和數據控管原則。 共用 AKS 叢集面臨較高的數據外洩、未經授權的存取，以及不符合數據保護法規的風險。 每個租使用者可能都有獨特的資料控管需求和合規性原則，因此難以確保數據的安全性和隱私權。

Microsoft適用於容器的 Defender 是雲端原生容器安全性解決方案，可為 Kubernetes 環境提供威脅偵測和保護功能。 藉由使用適用於容器的 Defender，您可以在 Kubernetes 叢集中裝載多個租使用者時，增強數據控管和合規性狀態。 使用適用於容器的 Defender 來協助保護敏感數據、透過分析容器行為和網路流量來偵測和回應威脅，並符合法規需求。 它提供稽核功能、記錄管理和報告產生，以示範法規和稽核者的合規性。

貢獻

本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。

主體作者：

其他參與者：