在 Azure Kubernetes Service (AKS) 中隔離叢集的最佳做法

您在管理 Azure Kubernetes Service (AKS) 中的叢集時,往往需要隔離小組和工作負載。 AKS 可讓您彈性決定要如何執行多租用戶叢集和隔離資源。 若要最大化您的 Kubernetes 投資,請先瞭解並實行 AKS 的多租使用者和隔離功能。

這個最佳做法文章著重於叢集操作員的隔離操作。 在本文中,您將學會如何:

  • 規劃多租用戶叢集和隔離資源
  • 在您的 AKS 叢集中使用邏輯或實體隔離

設計多租用戶的叢集

Kubernetes 可讓您以邏輯方式隔離相同叢集中的小組和工作負載。 其目標是要提供最少的許可權,範圍設定為每個小組所需的資源。 Kubernetes 命名空間 會建立邏輯隔離界限。 隔離和多租使用者的其他 Kubernetes 功能和考慮包含下列領域:

排程

排程 會使用基本功能,例如資源配額和 pod 中斷預算。 如需這些功能的詳細資訊,請參閱 AKS 中基本排程器功能的最佳做法

更先進的排程器功能包括:

  • 汙點和容許處
  • 節點選取器
  • 節點和 pod 親和性或反親和性。

如需這些功能的詳細資訊,請參閱 AKS 中進階排程器功能的最佳做法

網路

網路功能會使用網路 原則來控制進出 pod 的流量。

驗證和授權

驗證和授權 會使用:

  • 角色型存取控制 (RBAC)
  • Azure Active Directory (AD) 整合
  • Pod 身分識別
  • Azure 金鑰保存庫中的秘密

如需這些功能的詳細資訊,請參閱 AKS 中驗證和授權的最佳做法

容器

容器 包括:

  • 適用于 AKS 的 Azure 原則附加元件,可強制執行 pod 安全性。
  • 使用 pod 安全性內容。
  • 掃描映射與執行時間是否有弱點。
  • 使用應用程式盔甲或 Seccomp (的安全運算) ,以限制容器存取基礎節點的能力。

以邏輯方式隔離叢集

最佳做法指導方針

使用 邏輯隔離來分隔小組和專案。 將您部署的實體 AKS 叢集數目降至最低,以隔離小組或應用程式。

若使用邏輯隔離,單一 AKS 叢集將可用於多個工作負載、小組或環境。 Kubernetes 命名空間會形成工作負載和資源的邏輯隔離界限。

Logical isolation of a Kubernetes cluster in AKS

叢集的邏輯分隔通常會提供比實體隔離的叢集更高的 pod 密度,而叢集中的計算容量較少。 與 Kubernetes 叢集自動調整程式結合時,您可以相應增加或減少節點數目以符合需求。 這種最佳做法可透過只執行所需的節點數目,將成本降至最低。

目前,Kubernetes 環境對於惡意的多租使用者使用不是完全安全的。 在多租使用者環境中,有多個租使用者正在使用共同的共用基礎結構。 如果無法信任所有租使用者,您將需要進行額外的規劃,以防止租使用者影響其他人的安全性和服務。

額外的安全性功能,例如節點的 Kubernetes RBAC,可有效率地封鎖惡意探索。 若要在執行惡意多租使用者工作負載時獲得真正的安全性,您應該只信任虛擬程式。 Kubernetes 的安全性網域會成為整個叢集,而非個別節點。

對於這些類型的惡意多租用戶工作負載,您應使用實際隔離的叢集。

實體隔離叢集

最佳做法指導方針

針對個別的小組或應用程式部署,將實體隔離的使用降至最低。 相反地,請使用上一節所討論的「邏輯」隔離。

實際分隔 AKS 叢集是叢集隔離的常見方法。 在此隔離模型中,小組或工作負載會獲派自己的 AKS 叢集。 雖然實體隔離看起來就像是隔離工作負載或團隊的最簡單方式,但它會增加管理和財務負擔。 現在,您必須維護這些多個叢集,並個別提供存取權和指派許可權。 您也必須支付每個個別節點的費用。

Physical isolation of individual Kubernetes clusters in AKS

實際分隔的叢集通常有較低密度的 Pod。 因為每個小組或工作負載都有自己的 AKS 叢集,所以叢集通常會過度布建計算資源。 通常會在這些節點上排程少量的 pod。 取消認領節點容量無法用於其他小組開發中的應用程式或服務。 這些多餘的資源會導致實際分隔叢集的成本增加。

下一步

本文著重於叢集隔離。 如需 AKS 中叢集作業的相關詳細資訊,請參閱下列最佳作法: