適用於: ✔️ AKS Automatic ✔️ AKS Standard
您在管理 Azure Kubernetes Service (AKS) 中的叢集時,往往需要隔離小組和工作負載。 透過邏輯隔離,您可以針對多個工作負載、小組或環境使用單一 AKS 叢集。 Kubernetes 命名空間會形成工作負載和資源的邏輯隔離界限。 執行邏輯隔離牽涉到實作指令碼和流程來建立命名空間、設定資源限制、套用網路原則,以及透過角色型存取控制來授與團隊存取權。 了解如何在 Azure Kubernetes Service (AKS) 中使用受控命名空間,以簡化命名空間管理、叢集多租用戶服務和資源隔離。
叢集的邏輯區隔通常比實體隔離的叢集提供更高的Pod密度,同時可減少叢集中閒置的過剩計算容量。 與叢集自動調整程式或節點自動佈建結合時,您可以相應地增加或減少節點數目來符合需求。 這種最佳做法的方法會透過僅執行所需數目的節點來將成本降至最低。
網路原則
網路政策 是你可以用來控制 pod、命名空間和外部端點之間流量流動的 Kubernetes 資源。 網路原則可讓您定義輸入 (傳入) 和輸出 (傳出) 流量的規則,以確保只允許授權的通訊。 藉由套用網路原則,您可以增強叢集內工作負載的安全性和隔離性。
備註
允許相同命名空間的預設輸入網路原則規則會選擇預設安全性原則。 如果您需要 Kubernetes Service、輸入或閘道能夠從其部署的命名空間之外存取 (例如從部署在個別命名空間中的輸入控制器存取),則您需要選取 [允許全部]。 接著你可以套用自己的網路政策,限制 Ingress 只能從該命名空間進行。
受控命名空間會隨附一組內建原則。
- 允許全部:允許所有網路流量。
- 允許相同的命名空間:允許相同命名空間內的所有網路流量。
- 全部拒絕:拒絕所有網路流量。
您可以在輸入和輸出規則上套用任何的內建原則,而它們具有下列預設值。
| 原則 | 預設值 |
|---|---|
| 輸入 | 允許相同的命名空間 |
| 輸出 | 允許全部 |
備註
使用者若在其指派的 Microsoft Entra ID 角色上具有 Microsoft.ContainerService/managedClusters/networking.k8s.io/networkpolicies/write 動作,例如 Azure Kubernetes Service RBAC Writer,便可以透過 Kubernetes API 新增更多網路政策。
例如,如果管理員套用 Deny All 進出政策,使用者透過 Kubernetes API 套用 Allow 命名空間策略,該 Allow 政策優先於該 Deny All 政策,流量便可流向該命名空間。
資源配額
資源配額是 Kubernetes 資源,可用來管理和限制叢集中命名空間的資源使用量。 它們允許管理員定義對命名空間中工作負載使用的 CPU、記憶體、儲存空間或其他資源的限制。 透過套用資源配額,您可以確保資源的公平分配、防止資源過度使用,並維護叢集穩定性。
可以使用下列資源配額來建立受控命名空間:
- CPU 要求數和限制數:定義命名空間中工作負載可以要求或取用的最小和最大 CPU 資源數量。 配額確保工作負載有足夠的 CPU 資源運作,同時防止過度使用,避免影響其他命名空間。 配額定義於 milliCPU 格式中。
-
記憶體要求數和限制數:指定命名空間中工作負載可以要求或取用的最小和最大記憶體資源數量。 透過避免記憶體過度分配和確保跨命名空間的公平資源分配,配額有助於維護穩定性。 配額是以 2 的次方等價形式定義,例如
Ei、Pi、Ti、Gi、Mi、Ki。
標籤和註釋
Kubernetes 標籤和註釋是附加到 Kubernetes 物件 (例如命名空間) 的中繼資料,用於提供其他資訊。 標籤可用來組織和選取資源的索引鍵/值組,從而實現有效的分組和查詢。 註解儲存非識別性的元資料,例如配置細節或操作指令,這些資料會被工具或系統所使用。
您可以選擇性地設定要套用在命名空間上的 Kubernetes 標籤和註釋。
採用原則
採用原則可決定在 Kubernetes 中建立受控命名空間時如何處理現有的命名空間。
警告
將現有命名空間導入管理可能會造成干擾。 如果套用的資源配額小於 Pod 已要求的資源量,則超出配額的新部署和 Pod 會被拒絕。 現有部署不會受影響,但擴展功能被拒絕。 對現有命名空間套用 網路政策 可能會影響現有流量。 確保對原則進行測試和驗證,以避免意外中斷 Pod 或外部端點之間的通訊。
有下列選項可供使用:
- Never:如果命名空間已存在於叢集中,嘗試建立該命名空間作為受控命名空間會失敗。
- IfIdentical:如果現有的命名空間與所需的組態之間沒有差異,則會接管要被管理的現有命名空間。
- Always:一律會接管要被管理的現有命名空間 (即使命名空間中的某些欄位可能會被覆寫也一樣)。
刪除原則
刪除原則會指定在刪除受控命名空間資源時如何處理 Kubernetes 命名空間。
警告
使用 Delete 原則刪除受控命名空間會導致刪除該命名空間中的所有資源 (例如部署、服務、輸入和其他 Kubernetes 物件)。 確保在繼續進行之前先備份或移轉任何重要的資源。
有下列選項可供使用:
-
Keep:僅刪除受控命名空間資源,同時保持 Kubernetes 命名空間完整。 此外,
ManagedByARM標籤會從命名空間中移除。 - Delete:同時刪除受控命名空間資源和 Kubernetes 命名空間。
受控命名空間內建角色
受控命名空間會針對控制平面使用下列內建角色。
| 角色 | 說明 |
|---|---|
| Azure Kubernetes Service 命名空間參與者 | 允許在叢集上建立、更新和刪除受控命名空間。 |
| Azure Kubernetes Service 命名空間使用者 | 允許對叢集上的受控命名空間進行唯讀存取。 允許列出命名空間上的認證。 |
受控命名空間會針對資料平面使用下列內建角色。
| 角色 | 說明 |
|---|---|
| Azure Kubernetes Service RBAC 讀取者 | 允許唯讀存取來查看命名空間中的大部分物件。 其不允許檢視角色或角色繫結。 此角色不允許檢視秘密,因為讀取祕密的內容可存取命名空間中的 ServiceAccount 認證,這會允許 API 以命名空間中任何 ServiceAccount 身分來進行存取 (權限提升的形式)。 |
| Azure Kubernetes Service RBAC 寫入者 | 允許命名空間中大部分物件的讀取/寫入存取權。 不允許檢視或修改角色或角色繫結。 然而,此角色允許以命名空間中的任何 ServiceAccount 身分存取秘密並執行 Pod,因此可用來取得命名空間中任何 ServiceAccount 的 API 存取層級。 |
| Azure Kubernetes Service RBAC 管理員 | 允許對命名空間中的大部分資源進行讀取/寫入,包括在命名空間內建立角色和角色繫結的功能。 此角色不允許對資源配額或命名空間本身進行寫入存取。 |
受管理命名空間的使用案例
設置帶有相應配額或網路政策的命名空間可能既複雜又耗時。 受管理命名空間允許你在 AKS 叢集中設定預先設定的命名空間,並可透過 Azure CLI 與之互動。
以下章節概述了一些受管理命名空間的常見使用情境。
管理 AKS 上的團隊和資源
假設你是小型新創公司的管理員。 你已經配置好 AKS 叢集,想為 財務、 法務和 設計 團隊的開發者設置命名空間。 在建立公司環境時,你要確保存取權限受到嚴格控制,資源範圍正確,環境也妥善組織。
財務團隊會接收來自公司各團隊的表格和檔案,但他們持有一些敏感資訊,理想狀況下這些資訊不應該外洩。 他們的應用程式和工作流程在運算端較輕,但記憶體消耗很大。 因此,你決定建立一個命名空間,允許所有網路入口、僅在其命名空間內的網路出口,並相應地調整資源範圍。 命名空間的標籤有助於輕鬆辨識是哪個團隊在使用。
az aks namespace add \ --name $FINANCE_NAMESPACE \ --cluster-name $CLUSTER_NAME \ --resource-group $RESOURCE_GROUP \ --cpu-request 250m \ --cpu-limit 500m \ --memory-request 512Mi \ --memory-limit 2Gi \ --ingress-policy AllowAll \ --egress-policy AllowSameNamespace \ --labels team=finance法律團隊主要處理敏感資料。 他們的應用程式使用相當多的記憶體,但對運算資源的需求卻很少。 你決定設定一個對進出政策都極為嚴格的命名空間,並相應地設定資源配額範圍。
az aks namespace add \ --name $LEGAL_NAMESPACE \ --cluster-name $CLUSTER_NAME \ --resource-group $RESOURCE_GROUP \ --cpu-request 250m \ --cpu-limit 500m \ --memory-request 2Gi \ --memory-limit 5Gi \ --ingress-policy DenyAll \ --egress-policy DenyAll \ --labels team=legal設計團隊需要能夠自由流動地處理資料,在整個公司展示他們的作品。 他們也鼓勵團隊寄送內容供參考。 他們的應用程式非常密集,需要大量記憶體和 CPU。 你決定為他們設置一個限制最小的命名空間,並為他們分配大量資源。
az aks namespace add \ --name $DESIGN_NAMESPACE \ --cluster-name $CLUSTER_NAME \ --resource-group $RESOURCE_GROUP \ --cpu-request 2000m \ --cpu-limit 2500m \ --memory-request 5Gi \ --memory-limit 8Gi \ --ingress-policy AllowAll \ --egress-policy AllowAll \ --labels team=design
有了這些命名空間,你現在就擁有了組織中三個團隊的環境,讓每個團隊都能在最適合自己需求的環境中運作。 管理員可以利用 Azure CLI 呼叫 根據需求更新命名空間。
檢視管理命名空間
隨著你接觸的團隊數量增加,或組織成長,你可能會發現自己需要檢視所設定的命名空間。
假設你想檢視 前一節 叢集中的命名空間,以確保有三個命名空間。
使用 az aks namespace list 指令來檢視你的命名空間。
az aks namespace list \
--cluster-name $CLUSTER_NAME \
--resource-group $RESOURCE_GROUP \
--output table
您的輸出看起來應類似下列的範例輸出:
Name ResourceGroup Location
------------------ --------------- ----------
$CLUSTER_NAME/$DESIGN_NAMESPACE $RESOURCE_GROUP <LOCATION>
$CLUSTER_NAME/$LEGAL_NAMESPACE $RESOURCE_GROUP <LOCATION>
$CLUSTER_NAME/$FINANCE_NAMESPACE $RESOURCE_GROUP <LOCATION>
控制對受管理命名空間的存取
你還可以利用 Azure RBAC 角色,針對每個命名空間設界,來判斷哪些使用者能存取該命名空間內的特定動作。 透過適當的設定,你可以確保使用者在命名空間內擁有所需的所有存取權,同時限制他們對其他命名空間或整個叢集資源的存取。
後續步驟
- 了解如何在 Azure Kubernetes Service (AKS) 上建立和使用受控命名空間。
- 學習使用 Azure Kubernetes Fleet Manager 的 多叢集管理命名空間 。