Azure Kubernetes Service (AKS) 中叢集隔離的最佳做法
您在管理 Azure Kubernetes Service (AKS) 中的叢集時，往往需要隔離小組和工作負載。 AKS 讓您靈活執行多租用戶叢集和隔離資源。 若要在 Kube 投資方面獲得最大收益，請務必了解 AKS 多租用戶和隔離功能。
這個最佳做法文章著重於叢集操作員的隔離操作。 在本文中，您將學會如何：
- 規劃多租用戶叢集和資源隔離。
- 在 AKS 叢集中使用邏輯或實體隔離。
設計多租用戶的叢集
Kubernetes 可讓您邏輯式隔離相同叢集中的小組和工作負載。 目標是提供最少數量的權限，並將其範圍限制在每個小組需要的資源。 Kubernetes 命名空間會建立邏輯隔離界限。 隔離和多租用戶的其他 Kube 功能和注意事項如下：
正在排程
排程使用資源配額和 Pod 中斷預算等基本功能。 如需這些功能的詳細資訊，請參閱 AKS 中基本排程器功能的最佳做法。
進階排程器功能包含：
- 污點和容忍。
- 節點選取器。
- 節點及 Pod 親和性或反親和性。
如需這些功能的詳細資訊，請參閱 AKS 中進階排程器功能的最佳做法。
網路
網路使用網路原則來控制 Pod 流入和流出流量。
如需詳細資訊，請參閱在 AKS 中使用網路原則來保護 Pod 之間的流量。
驗證與授權
驗證與授權：
- 角色型存取控制 (RBAC)。
- Microsoft Entra 整合。
- Pod 身分識別。
- Azure Key Vault 中的祕密。
如需這些功能的詳細資訊，請參閱 AKS 中驗證和授權的最佳做法。
容器
容器包含：
- AKS 的 Azure 原則附加元件。用於強制執行 Pod 安全性。
- Pod 安全性許可。
- 掃描影像及執行階段，檢查是否有弱點。
- 使用 App Armor 或 Seccomp (安全運算) 以限制容器存取基礎節點。
邏輯隔離叢集
最佳做法指導
使用邏輯隔離來分隔小組和專案。 盡量減少隔離小組或應用程式所部署的實體 AKS 叢集數。
透過邏輯隔離，您可以針對多個工作負載、小組或環境使用單一 AKS 叢集。 Kube 命名空間構成了工作負載和資源的邏輯隔離界限。
叢集的邏輯區隔通常提供比實體隔離叢集更高的 Pod 密度，且叢集中的計算容量不足。 與 Kubernetes 叢集自動調整程式結合時，您可以相應增加或減少節點數目以符合需求。 這個最佳做法方法只會執行所需的節點數目，將成本降至最低。
就多租用戶惡意使用方式而言，Kube 環境並不完全安全。 在多租用戶環境中，多個租用戶會共用同一個基礎結構。 若無法信任所有租用戶，您需要額外規劃，以防有租用戶影響其他租用戶的安全性和服務。
其他安全性功能（例如適用於節點的 Kube RBAC）可有效阻擋惡意探索。 執行嚴格控管式多租用戶工作負載時，若要真正確保安全性，應只信任 Hypervisor。 Kube 的安全性網域會成為整個叢集，而不是單一節點。
針對這些類型的惡意多租用戶工作負載，您應該使用實際隔離的叢集。
實體隔離叢集
最佳做法指導
請盡量少用各獨立團隊或應用程式部署的實體隔離；請改用邏輯隔離。
實際分隔 AKS 叢集為叢集隔離的常見方法。 在此隔離模型中，小組或工作負載會獲派自己的 AKS 叢集。 實體隔離看起來雖是隔離工作負載或小組最簡單的方式，但也會增加管理和財務上的額外負荷。 若採用實體隔離叢集，您必須維護多個叢集並單獨提供存取和指派權限。 您也需要為每個單一節點付費。
實體隔離叢集的 Pod 密度通常較低。 由於每個小組或工作負載皆有自己的 AKS 叢集，因此叢集往往會過度佈建運算資源。 通常會在這些節點上安排一些 Pod。 其他小組也無法使用未宣告的節點容量來開發應用程式或服務。 多餘的資源會增加實體隔離叢集的成本。
下一步
本文著重於叢集隔離。 有關 AKS 中叢集作業的詳細資訊，請參閱以下最佳做法的相關文章：
