本文介紹了該 ResourcePlacement API，該 API 允許使用 Azure Kubernetes Fleet Manager 對成員叢集間命名空間範圍的 Kubernetes 資源進行細緻控制。
這很重要
Azure Kubernetes Fleet Manager 預覽功能可在自助服務、選擇加入的基礎上使用。 預覽是「依現況」及「可用時」提供的，並不包括在服務等級協定和有限保固之內。 客戶支援部門會竭盡全力支援一部分的 Azure Kubernetes 機群管理員預覽功能。 因此，這些功能不適合實際執行用途。
概觀
ResourcePlacement 是一個命名空間範圍的 API，能動態選擇並實現命名空間範圍資源的多叢集傳播。 它提供細緻控制，控制命名空間內特定資源如何在車隊成員叢集間分配。
這很重要
ResourcePlacement 使用 placement.kubernetes-fleet.io/v1beta1 API 版本，目前正處於預覽階段。 本文中展示的一些功能，例如 selectionScope 在 ClusterResourcePlacement 中，也是 v1beta1 API 的一部分，但不在 v1 API 中提供。
主要特性：
-
命名空間範圍：
ResourcePlacement物件及其管理的資源都存在於同一個命名空間中。 - 選擇性：可依類型、名稱或標籤針對特定資源，而非整個命名空間。
-
宣告式：使用與
ClusterResourcePlacement一致的放置模式以確保相同的行為。
A ResourcePlacement 包含三個核心組件：
- 資源選擇器：定義要包含哪些命名空間範圍的資源。
-
定位政策：利用
PickAll、PickFixed或PickN策略決定目標群集。 - 部署策略：控制變更如何在選定叢集間傳遞。
何時使用 ResourcePlacement
ResourcePlacement 適用於需要對命名空間範圍資源進行細緻控制的情境：
- 選擇性資源分配：部署特定的 ConfigMap、Secret 或服務，且不影響整個命名空間。
- 多租戶環境：允許不同團隊在共享命名空間中獨立管理資源。
- 組態管理：將特定環境的配置分散到不同的叢集環境。
- 合規與治理：在同一命名空間內，對不同資源類型套用不同政策。
- 漸進式部署：以零停機策略安全地部署資源更新於叢集間。
在多叢集環境中，工作負載通常同時包含叢集範圍與命名空間範圍的資源，需分散於不同叢集間。 雖然 ClusterResourcePlacement （CRP）能有效處理叢集範圍的資源，整個命名空間及其內容，但有些情況下，你需要對現有命名空間內的命名空間範圍資源進行更細緻的控制。
ResourcePlacement （RP）旨在填補這一缺口，提供：
- 命名空間範圍資源管理：在不影響整個命名空間的情況下，針對特定命名空間中的資源進行目標設定。
- 營運彈性：允許團隊獨立管理同一命名空間內的不同資源。
- 互補功能：與 CRP 協同工作，提供完整的多叢集資源管理解決方案。
備註
ResourcePlacement 可在僅命名空間模式下與 ClusterResourcePlacement 一起使用。 例如，你可以使用 CRP 部署命名空間，同時使用 RP 來細緻管理特定資源，例如該命名空間內的環境專屬 ConfigMaps 或 Secret。
現實世界的命名空間使用模式
雖然 CRP 假設命名空間代表應用程式邊界，但實際世界的使用模式往往更為複雜。 組織經常將命名空間作為團隊邊界而不是應用程式邊界，這導致了幾個挑戰，而ResourcePlacement旨在直接應對這些挑戰。
多應用程式命名空間：在許多組織中，單一命名空間包含多個由同一團隊擁有的獨立應用程式。 這些應用可能包括：
- 不同的生命週期需求（一個應用程式可能需要頻繁更新，而另一個則保持穩定）。
- 不同的叢集配置需求（開發與生產應用）。
- 獨立調整與資源需求。
- 各自的合規或治理要求。
個別排程決策：許多工作負載，特別是 AI/ML 工作，都需要個別排程決策：
- AI 工作：機器學習工作負載通常為短命且耗資源密集的工作，需根據叢集資源可用性、GPU 可用性或資料區域性來排程。
- 批次工作負載：同一命名空間內的不同批次工作可能根據計算需求針對不同的叢集類型。
完整的應用程式團隊控制： ResourcePlacement 讓應用程式團隊能直接掌控資源配置，無需平台團隊介入：
- 自助營運：團隊可以自行管理資源分配策略。
- 獨立部署週期：同一命名空間內的不同應用程式可以有獨立的部署排程。
- 細節覆寫功能：團隊可自訂每個叢集的資源配置，但不影響命名空間中的其他應用程式。
這種細緻的方法確保公司 ResourcePlacement 能適應多元的組織結構與工作量模式，同時維持車隊排程框架的簡潔與強大功能。
ResourcePlacement 與 ClusterResourcePlacement 的主要差異
以下表格突顯了 ResourcePlacement 和 ClusterResourcePlacement 之間的主要差異：
| 層面 | 資源置放（RP） | 叢集資源置入（ClusterResourcePlacement，CRP） |
|---|---|---|
| Scope | 僅限於命名空間範圍的資源 | 叢集範圍資源（尤其是命名空間及其內容） |
| 資源 | 命名空間範圍的 API 物件 | 集群範圍的 API 物件 |
| 選擇邊界 | 限制為命名空間與保留點相同的資源 | 可以選擇任何叢集範圍內的資源 |
| 典型用例 | AI/ML 任務、個別工作負載、需要獨立刊登位置決策的特定 ConfigMaps/密碼 | 應用程式套件、整個命名空間、叢集範圍的政策 |
| 球隊所有權 | 可由命名空間擁有者/開發者管理 | 通常由平台營運商管理 |
兩者在ResourcePlacementClusterResourcePlacement差異表中未列出的其他面向共享相同核心能力。
與 ClusterResourcePlacement 合作
ResourcePlacement 設計上與 ClusterResourcePlacement（CRP）協同運作，以提供完整的多叢集資源管理解決方案。 了解這種關係對於有效管理車隊至關重要。
命名空間的先決條件
這很重要
ResourcePlacement 只能將命名空間範圍的資源放置到已經擁有目標命名空間的叢集。 我們建議用於 ClusterResourcePlacement 建立命名空間。
典型工作流程：
-
平台管理員：用於
ClusterResourcePlacement在整個車隊部署命名空間。 -
應用程式團隊：用於
ResourcePlacement管理這些已建立命名空間中的特定資源。
以下範例說明如何協調CRP與RP：
備註
以下範例使用 placement.kubernetes-fleet.io/v1beta1 API 版本。 這個 selectionScope: NamespaceOnly 欄位是 v1beta1 中可用的預覽功能，v1 API 中沒有。
平台管理員：首先，請使用以下方式 ClusterResourcePlacement建立命名空間：
apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
name: app-namespace-crp
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: my-app
version: v1
selectionScope: NamespaceOnly # only namespace itself is placed, no resources within the namespace
policy:
placementType: PickAll # If placement type is not PickAll, the application teams needs to know what are the clusters they can place their applications.
應用團隊：接著，使用以下方式 ResourcePlacement管理命名空間內的特定資源：
apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ResourcePlacement
metadata:
name: app-configs-rp
namespace: my-app
spec:
resourceSelectors:
- group: ""
kind: ConfigMap
version: v1
labelSelector:
matchLabels:
app: my-application
policy:
placementType: PickFixed
clusterNames:
- cluster1
- cluster2
最佳做法
使用 ResourcePlacement 和 ClusterResourcePlacement 時，請遵循以下最佳實務：
-
先建立命名空間：在建立
ResourcePlacement物件前，務必確保命名空間是透過 CRP 部署的。 - 監視相依性：使用機群監視確保命名空間層級的 CRP 在部署相依 RP 前保持良好狀態。
- 協調政策：對齊 CRP 與 RP 的放置策略以避免衝突（例如，若 CRP 將命名空間置於叢集 A、B、C，RP 可鎖定這些叢集的任何子集）。
- 團隊邊界：平台管理資源（命名空間、RBAC）使用CRP，應用程式管理資源（應用程式設定、秘密）使用RP。
這種協調的做法確保 ResourcePlacement 團隊在維持由平台營運商管理的基礎基礎設施的同時，提供團隊所需的彈性。
資源選擇、放置與推廣
ResourcePlacement 使用與以下相同的擺放模式 ClusterResourcePlacement：
-
配置類型：
PickAll、、PickFixed以及PickN策略在兩個 API 上運作方式相同。 - 推出策略：控制更新如何在使用相同滾動更新機制的叢集間傳播。
- 狀態與可觀察性：使用
kubectl describe resourceplacement <name> -n <namespace>監控部署進度。 - 進階功能：使用容忍度、資源覆蓋、拓撲擴散約束及親和力規則。
關鍵差異在於 資源選擇 範圍。 雖然 ClusterResourcePlacement 通常會選擇整個命名空間及其內容，但 ResourcePlacement 能對個別命名空間範圍內的資源提供細緻的控制。
欲了解這些功能的完整細節，請參閱 ClusterResourcePlacement 文件。