*作者：*

*邱見｜紅帽資深軟體工程師，Open Cluster Management (OCM) 社群發起人，負責人*

*郝青｜紅帽高階軟體工程師，Open Cluster Management (OCM) 社群維護者*

Open Cluster Management(OCM) 專案已經在 2021 年 11 月 9 日成為 CNCF 的沙箱專案。OCM 作為一個社群驅動的專案，專注於 Kubernetes 應用程式的多叢集和多雲場景。

最新 OCM 社群版本 0.6.0 已於 2022 年 1 月 21 日正式釋出。詳細內容可訪問 Open Cluster Management 0.6 釋出 **[1]** 。

在多叢集環境中，不同角色的使用者對多叢集操作有著不同的需求。比如管理員等使用者需要對目標叢集進行一些配置, 應用程式開發人員可能希望將工作負載部署到特定叢集，這些工作負載可以是 Kubernetes 的 Service、Deployment、ConfigMap 或不同 Kubernetes 物件的捆綁包。這些使用者對目標叢集會有一些要求，比如：

-   我只想在 Amazon Web Services(AWS) 上配置叢集。
-   我只想將工作負載部署到標籤為 group=dev 的叢集上。
-   我希望工作負載始終在具有最大可分配記憶體的 3 個叢集上執行。

為了選擇出目標叢集，可以選擇在部署管道 (deploy pipeline) 中對直接指定目標叢集名稱，或使用某種形式的標籤選擇器。對於對資源有要求的工作負載，需要一個細粒度的排程器來將工作負載分發到具有足夠資源的群集。當群集屬性更改時，排程結果應該保持動態更新。

在 OCM 中，前面描述的排程功能是透過 Placement 來實現的。在這篇文章中，將介紹 Placement 如何選擇到所需的叢集，Placement 可以提供的排程功能，以及一些場景下的最佳實踐，使用者可以參考示例來編寫符合自己要求的 Placement。其他一些高階排程功能，如支援汙點 (taints) 和容忍 (tolerations)，以及拓撲選擇 (spread)，正在 OCM 社群 **[2]** 討論中。

在閱讀本文前，可訪問以下連結瞭解相關基本概念:

-   ManagedCluster 和 ManagedClusterSet **[3]**
-   Placement **[4]**

## 為什麼我們需要ManagedClusterSet？

“ClusterSet”是在 Kubernetes SIG 多叢集工作小組的“多叢集服務 (MultiClusterService/MCS)”API 中已經實踐許久的概念，它意指多個擁有相同屬性/特徵的“叢集小組”的概念。在多叢集網路的場景裡我們需要根據底座基礎設施的拓撲為叢集分組，同樣的在 OCM 多叢集管理平臺裡我也可以根據叢集的場景用途，工作特性具體分組。這也是 OCM 引入 ClusterSet 模型的最初緣由之一。

在此基礎上，OCM 在引入多叢集分組的語義的同時考慮到了不同分組之間的“軟租戶隔離性” — 尤其考慮到不同叢集小組可能是由不同的角色/團隊去維護的，同時這些團隊之間應該相互自治不干擾。在 OCM 的世界中，我們會允許管理員為每一種角色/團隊會分配一個名稱空間/namespace，同時透過利用 Kubernetes 原生提供的名稱空間之間的隔離性使不同角色區別開來（其中所謂的角色落進實際場景裡可以是一個應用或者也可以是一個組織團隊等等）。那麼這些角色只要在被分配的名稱空間裡活動就可以充分編排所關聯的多個叢集上的資源。

總而言之，在一個通用的多叢集中樞控制平面裡，如何解決多個使用者/角色分離的問題其實是最首要的問題之一，OCM 之所以引入了 ClusterSet 模型且額外提供了其到名稱空間的對映，是為了希望 OCM 作為一個平臺能解決“多叢集場景”裡幫助使用者解決最瑣碎同時又最操心的問題。至於如何消費所關聯的叢集列表請參考下面的 Placement 模型。

## 什麼是 Placement？

Placement API 用於在一個或多個託管叢集組(ManagedClusterSet)中選擇一組託管群集(ManagedCluster)，以便將工作負載部署到這些群集上。

如果定義了有效的 Placement，則 Placement 控制器 (controller) 將生成相應的排程決策 (PlacementDecision)，並在狀態 (Status) 中列出選定的託管群集 (ManagedCluster)。作為終端使用者，你可以解析出選定的叢集，然後對目標叢集進行操作。你也可以將更高層級的工作負載編排器 (orchestrator) 與 PlacementDecision 整合，來擴充套件 Placement 的排程能力。

例如，ArgoCD 已經與 Placement 整合。ArgoCD 的使用者可以在 ApplicationSet 的 clusterDecisionResource 中指定一個關聯了的 PlacementDecision 資源的 ConfigMap，就可以利用 Placement 的排程決策，將應用自動分配到一組目標叢集。如下：

```
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: book-import
spec:
  generators:
    - clusterDecisionResource:
        configMapRef: ocm-placement
        labelSelector:
          matchLabels:
            cluster.open-cluster-management.io/placement: local-cluster
        requeueAfterSeconds: 30
  template:
…

apiVersion: v1
kind: ConfigMap
metadata:
  name: ocm-placement
data:
  apiVersion: cluster.open-cluster-management.io/v1alpha1
  kind: placementdecisions
  statusListKey: decisions
  matchKey: clusterName

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: PlacementDecision
metadata:
  labels:
    cluster.open-cluster-management.io/placement: local-cluster
  name: local-cluster-decision-1
status:
  decisions:
  - clusterName: cluster1
    reason: ""
  - clusterName: cluster2
    reason: ""
```

KubeVela 作為開放應用程式模型 OAM(Open Application Model) 的實現，也即將利用 Placement API 進行工作負載排程。

### 與原生 Kubernetes 排程模型的區別與聯絡？

與 Kubernetes 的**靜態排程**不同，Placement 使用**動態排程**的機制。排程抉擇會隨著叢集屬性變化也隨之改變，使用者可以透過在 Placement 上調整排程的穩定值來減少排程決策的抖動。另外，Placement API 嘗試將整個排程過程顯示化，讓使用者可以透過 API 查詢排程抉擇的原委，方便使用者更加容易的除錯排程配置和引數。

同時在原生 Kubernetes 中的排程是**一次性**的，而在多叢集場景裡我們往往需要的是一個“**宣告式的排程**” — 我們定義出排程策略的“硬條件”和“軟條件”是什麼，再根據實際的叢集拓撲/實時狀態決策最終匹配的叢集，所以它更像是原生 Kubernetes 中的驅散排程/反排程 PodDisruptionBudget 的模型而非靜態排程中的 Taint/Toleration 的模型。

OCM 在 Placement 模型中同時考慮到了大規模多叢集排程時叢集列表長度暴漲的問題，在 Placement 的匹配產物 PlacementDecision 中所有匹配結果都是分頁展示的以避免突破 Kubernetes CRD 對模型的限制。

## Placement 如何選擇叢集？

有了上述的初步介紹，讓我們更深入地瞭解 Placement API，看看它是如何選擇所需的叢集以及它可以提供哪些排程功能。

如下是一個 Placement 例子：

```
apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 4
  clusterSets:
    - clusterset1
    - clusterset2
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            vendor: OpenShift
  prioritizerPolicy:
    mode: Exact
    configurations:
      - scoreCoordinate:
          builtIn: ResourceAllocatableMemory
      - scoreCoordinate:
          builtIn: Steady
        weight: 3
      - scoreCoordinate:
          type: AddOn
          addOn:
            resourceName: default
            scoreName: cpuratio
```

Spec 包含以下四個欄位：

-   numberOfClusters: 表示要選擇的符合要求的 ManagedClusters 數量。

-   clusterSets: 表示從中選擇 ManagedCluster 的 ManagedClusterSet 名稱。

-   predicates: 包括了一組預選策略。可以使用標籤選擇器 (labelSelector) 和宣告選擇器 (claimSelector) 來選擇 ManagedCluster。每一個預選策略配置之間是或的關係。

-   prioritizerPolicy: 定義了優選策略。優選策略中透過 mode 設定是否使用預設的優選器 (prioritizer)。同時也可以在 configurations 中配置具體的優選器 (prioritizer)。目前 Placement 內建支援的優選器 (prioritizer) 包括平衡 (Balance)，穩定 (Steady)，最大可分配CPU資源 (ResourceAllocatableCPU) 和最大可分配記憶體資源 (ResourceAllocatableMemory)。Placement 同時也支援透過第三方提供的分數來選擇叢集。weight 權重是一個 -10 到 10 的整數，用以調整不同的優選器打分對總分的影響。

如果未定義 Spec 中各欄位的值，則使用預設值。每個欄位中預設值的詳細資訊在 PlacementSpec **[5]**  中定義。

如果 Spec 為空，所有繫結到 Placement 名稱空間 (namespace) 的 ManagedClusterSet 中的所有 ManagedCluster 將作為可能的選項。

以上每個欄位的定義都在排程中發揮著作用。如下是一個典型的排程過程：

1.  排程框架首先從 clusterSets 中定義的 ManagedClusterSet 中選擇出可用的 ManagedCluster。

2.  過濾器外掛 (filter plugin) 透過預選策略 predicates 中定義的標籤 (label) 和宣告 (claim) 選擇器進一步篩選 ManagedCluster。

3.  在優選策略 prioritizerPolicy 啟用的優選器外掛 (prioritizer plugin) 會為每個篩選後的 ManagedCluster 打一個分數，並且按總分從高到低確定優先順序。

4.  排程框架會選擇前 k 個 ManagedCluster，並把這些叢集列在 PlacementDecision 中。k 的值是在 numberOfClusters 定義的叢集數量。

如果將以上步驟對應的上述的例子中，排程過程如下：

1.  排程框架首先選擇 ManagedClusterSet clusterset1 和 clusterset2 中的叢集作為可用的 ManagedCluster。
1.  過濾器外掛 (filter plugin) 篩選出帶有標籤 (label)vendor=OpenShift 的 ManagedCluster。
1.  優選器外掛 (prioritizer plugin)ResourceAllocatableMemory 和 Steady 為每一個篩選的 ManagedCluster 打分。當配置了優選策略 AddOn，Placement 會嘗試獲得叢集對應的第三方資源提供的分數 cpuratio。並用如下公式計算每個 ManagedCluster 的總分：

*1(ResourceAllocatableMemory 的預設權重) * ResourceAllocatableMemory 的打分 + 3(Steady 的權重) * Steady 的打分 + 1(AddOn 的預設權重) * cpuratio(AddOn 的分數)*

4.  排程框架按照每個 ManagedCluster 的總分從高到低排列，並返回最高分數的 ManagedCluster 作為結果。

在第 3 步優選器外掛工作時，實際上多個外掛的組合。每個外掛的演算法和權重都會影響最終的排程結果。下一節中，會更詳細的介紹每個外掛，以便你更好的瞭解 Placement是如何選擇 ManagedCluster 的。

## 優選器外掛如何工作？

在撰寫此文時，我們有如下四個預設的優選器：

-   平衡 (Balance): 平衡每個叢集上的排程決策 (PlacementDecision) 數量。擁有 PlacementDecision 數量最多的叢集將得到最低分 -100 分，如果沒有 PlacementDecision 則被賦予最高分 100 分。其他的分數介於 -100 到 100 之間。

-   穩定 (Steady): 確保現有的 PlacementDecision 中已選叢集的結果保持穩定。現有的 PlacementDecision 已經選中的叢集將得到最高分 100 分，沒有被選中的叢集得到最低分 0 分。

-   最大可分配 CPU 資源 (ResourceAllocatableCPU) 和最大可分配記憶體資源 (ResourceAllocatableMemory) 基於叢集的可分配 CPU 或者記憶體做決策。擁有最多可分配資源(CPU 或者記憶體)的叢集將得到最高分 100 分，擁有最少資源的叢集將得到最低分 -100分。其他的分數介於 -100 到 100 之間。

**優選策略 AddOn 還支援透過第三方提供的分數選擇叢集。這部分也是 Placement 在 OCM v0.6.0 中的最新功能。OCM v0.6.0 中提供了新的 API AddOnPlacementScore 用以支援一種基於自定義分數的更具可擴充套件性的排程方式。**

-   **作為使用者，可以在 yaml 檔案中 prioritizerPolicy 下配置 AddOn，來指定自定義分數以選擇叢集。**

-   **作為分數的提供者，第三方的控制器 (controller) 可以在中心 (Hub Cluster) 或託管群集 (Managed Cluster) 上執行，controller 需要維護 AddOnPlacementScore 的生命週期並將分數更新到其中。**

關於可擴充套件排程的更多詳細內容，可以參考社群文件 **[6]** 。

在做出排程決策時，ManagedCluster 按照最終的總分排序。總分是每個優選器的打分乘以權重的總和: 總分 = sum(prioritizer_x_weight * prioritizer_x_score)，其中 prioritizer_x_weight 是優選器 (prioritizer)X 的權重，prioritizer_x_score是優選器 (prioritizer)X 為一個 ManagedCluster 打的分數。

可以透過調整優選器 (prioritizer) 的權重來影響最終的分數，比如：

-   透過給資源型別的優選器 ResourceAllocatableCPU 和 ResourceAllocatableMemory 設定權重，來基於可分配的資源做排程。

-   透過給資源型別的優選器設定一個更高的權重，使得排程結果對於資源的變化更加敏感。

-   透過給優選器 Steady 設定更高的權重，使得排程結果可以忽略資源的變化保持穩定。

如下是一些實際的例子，來說明多個優選器是如何共同工作以得到最終的排程結果。這些例子也可以視為是在一些場景下的最佳實踐。

以下示例中假設有三個託管叢集 (ManagedCluster) 繫結在名稱空間 (namespace)ns1， 其中 cluster1，cluster2，cluster3 分別有 60MB，80MB 和 100MB 可分配記憶體。

### 示例 1：選擇具有最大可分配記憶體的叢集。

在此示例中，希望選擇具有最大可分配記憶體的叢集。為了按可分配記憶體對叢集進行優先順序排序，可以在優選策略 (prioritizerPolicy) 中配置ResourceAllocatableMemory。

```
apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: Placement
metadata:
  name: demo
  namespace: ns1
spec:
  numberOfClusters: 2
  prioritizerPolicy:
    configurations:
      - scoreCoordinate:
          builtIn: ResourceAllocatableMemory
```

Placement建立之後，可以透過oc describe placement命令，檢視events來了解優先順序排序是如何選中叢集的。

```
# oc describe placement demo -n ns1
Name:         demo
Namespace:    ns1
Labels:       <none>
Annotations:  <none>
API Version:  cluster.open-cluster-management.io/v1alpha1
Kind:         Placement
…
Status:
  Conditions:
    Last Transition Time:       2021-11-09T07:02:14Z
    Message:                    All cluster decisions scheduled
    Reason:                     AllDecisionsScheduled
    Status:                     True
    Type:                       PlacementSatisfied
  Number Of Selected Clusters:  2
Events:
  Type    Reason          Age   From                 Message
  ----    ------          ----  ----                 -------
  Normal  DecisionCreate  10s   placementController  Decision demo-decision-1 is created with placement demo in namespace ns1
  Normal  DecisionUpdate  10s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1
  Normal  ScoreUpdate     10s   placementController  cluster1:0 cluster2:100 cluster3:200
```

在這個例子中，在 Additive 模式下，優選器包括了預設權重為 1 的 Balance 和 Steady 以及顯示配置了權重為 1 的 ResourceAllocatableMemory。一個叢集的最終得分將由如下公式決定：

*1 * prioritizer_balance_score +  1 * prioritizer_steady_score +  1 * prioritizer_resourceallocatablememory_score*

從上面的 event 中可以看出來，cluster1 總分為 0，cluster2 總分為 100，cluster3 總分為 200。排程結果應該選擇 cluster2 和 cluster3。

可以透過 oc describe placementdecision 命令來驗證排程結果，如下：

```
# oc describe placementdecision demo-decision-1 -n ns1
Name:         demo-decision-1
Namespace:    ns1
Labels:       cluster.open-cluster-management.io/placement=placement-jkd42
Annotations:  <none>
API Version:  cluster.open-cluster-management.io/v1alpha1
Kind:         PlacementDecision
...
Status:
  Decisions:
    Cluster Name:  cluster2
    Reason:        
    Cluster Name:  cluster3
    Reason:        
Events:            <none>
```

可以看到，在 PlacementDecision 的 status 中，cluster2 和 cluster3 被列在其中。

讓我們嘗試新增一個新的叢集，並且這個叢集上有著比被選中叢集高出一些的可分配記憶體。

Placement 排程器會監視 (watch) 託管叢集。一旦有資源變化，將觸發重新排程。現在，讓我們試著新增一個有 100MB 可分配記憶體的新叢集 cluster4，同時檢查 Placement 中的事件 (event)。

```
# oc describe placement demo -n ns1
... 
Events:
  Type    Reason          Age   From                 Message
  ----    ------          ----  ----                 -------
  Normal  DecisionCreate  100s   placementController  Decision demo-decision-1 is created with placement demo in namespace ns1
  Normal  DecisionUpdate  100s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1
  Normal  ScoreUpdate     100s   placementController  cluster1:0 cluster2:100 cluster3:200
```

可以看到並沒有事件更新，排程結果也沒有發生變化。所以當我們新增一個僅僅比 cluster2 的記憶體高出 20MB 的 cluster4 時，排程結果並不會被影響。

讓我們嘗試新增一個新的叢集，並且這個叢集上有著比被選中叢集高出很多的可分配記憶體。

現在，讓我們試著新增一個有 150MB 可分配記憶體的新叢集 cluster4，同時再次檢查 Placement 中的事件 (event)。

```
# oc describe placement demo -n ns1
...
Events:
  Type    Reason          Age   From                 Message
  ----    ------          ----  ----                 -------
  Normal  DecisionCreate  2m10s   placementController  Decision demo-decision-1 is created with placement demo in namespace ns1
  Normal  DecisionUpdate  2m10s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1
  Normal  ScoreUpdate     2m10s   placementController  cluster1:0 cluster2:100 cluster3:200
  Normal  DecisionUpdate  3s      placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1
  Normal  ScoreUpdate     3s      placementController  cluster1:200 cluster2:145 cluster3:189 cluster4:200
```

這一次，排程結果更新了，Placement 被重新排程到了 cluster3 和 cluster4 上。

```
# oc describe placementdecision demo-decision-1 -n ns1
...
Status:
  Decisions:
    Cluster Name:  cluster3
    Reason:        
    Cluster Name:  cluster4
    Reason:
```

在上面這個例子中，當資源只發生了少許變化時，排程結果並不會被影響。而當資源發生比較大的變化時，變化會立刻反應在排程結果中。這樣便引發出如下 2 個挑戰：

-   如果希望排程結果對資源變化保持敏感，應該怎麼做？

-   如果希望排程結果保持穩定，忽略資源的變化，應該怎麼做？

還記得我們在 prioritizerPolicy 中有 4 個優選器並且可以調整他們的權重嗎？我們可以透過修改 prioritizerPolicy 的配置來解決上面兩個問題。

### 示例 2：選擇具有最大可分配記憶體的群集，並使 Placement 對資源變化保持敏感。

為了使排程結果對資源的變化敏感，這次我們顯式設定了優選器 ResourceAllocatableMemory，權重為 3。

```
apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: Placement
metadata:
  name: placement7
  namespace: ns1
spec:
  numberOfClusters: 2
  prioritizerPolicy:
    configurations:
      - scoreCoordinate:
          builtIn: ResourceAllocatableMemory
        weight: 3
```

當 Placement 建立好之後，讓我們透過 oc describe 命令來檢查 Placement 和 PlacementDecision 的結果。

```
# oc describe placement demo -n ns1
...
Status:
  Conditions:
    Last Transition Time:       2021-11-09T08:58:40Z
    Message:                    All cluster decisions scheduled
    Reason:                     AllDecisionsScheduled
    Status:                     True
    Type:                       PlacementSatisfied
  Number Of Selected Clusters:  2
Events:
  Type    Reason          Age   From                 Message
  ----    ------          ----  ----                 -------
  Normal  DecisionCreate  35s   placementController  Decision demo-decision-1 is created with placement demo in namespace ns1
  Normal  DecisionUpdate  35s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1
  Normal  ScoreUpdate     35s   placementController  cluster1:-200 cluster2:100 cluster3:400
# oc describe placementdecision demo-decision-1 -n ns1
...
Status:
  Decisions:
    Cluster Name:  cluster2
    Reason:        
    Cluster Name:  cluster3
    Reason:
```

初始的排程結果為 cluster2 和 cluster3。現在，讓我們試著再次加入一個有 100MB 可分配記憶體的叢集，然後檢查 Placement 事件。

```
# oc describe placement demo -n ns1
...
Events:
  Type    Reason          Age   From                 Message
  ----    ------          ----  ----                 -------
  Normal  DecisionCreate  3m1s  placementController  Decision demo-decision-1 is created with placement demo in namespace ns1
  Normal  DecisionUpdate  3m1s  placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1
  Normal  ScoreUpdate     3m1s  placementController  cluster1:-200 cluster2:100 cluster3:400
  Normal  DecisionUpdate  2s    placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1
  Normal  ScoreUpdate     2s    placementController  cluster1:-200 cluster2:200 cluster3:500 cluster4:400
```

這一次，PlacementDecision 更新了，並且結果重新排程到了 cluster3 和 cluster4。

```
# oc describe placementdecision demo-decision-1 -n ns1
...
Status:
  Decisions:
    Cluster Name:  cluster3
    Reason:        
    Cluster Name:  cluster4
    Reason:
```

### 示例 3：選擇具有最大可分配記憶體的叢集並穩定排程結果。

為了使排程結果保持穩定，這次我們顯式設定了優選器 Steady，並且設定權重為 3。

```
apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: Placement
metadata:
  name: demo
  namespace: ns1
spec:
  numberOfClusters: 2
  prioritizerPolicy:
    configurations:
      - scoreCoordinate:
          builtIn: ResourceAllocatableMemory
      - scoreCoordinate:
          builtIn: Steady
        weight: 3
```

Placement 建立好之後，再次透過 oc describe 命令來檢查 Placement 和 PlacementDecision 的結果。

```
# oc describe placement demo -n ns1
...
Status:
  Conditions:
    Last Transition Time:       2021-11-09T09:05:36Z
    Message:                    All cluster decisions scheduled
    Reason:                     AllDecisionsScheduled
    Status:                     True
    Type:                       PlacementSatisfied
  Number Of Selected Clusters:  2
Events:
  Type    Reason          Age   From                 Message
  ----    ------          ----  ----                 -------
  Normal  DecisionCreate  15s   placementController  Decision demo-decision-1 is created with placement demo in namespace ns1
  Normal  DecisionUpdate  15s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1
  Normal  ScoreUpdate     15s   placementController  cluster1:0 cluster2:100 cluster3:200
# oc describe placementdecision demo-decision-1 -n ns1
...
Status:
  Decisions:
    Cluster Name:  cluster2
    Reason:        
    Cluster Name:  cluster3
    Reason:
```

初始的排程結果為 cluster2 和 cluster3。

現在，讓我們試著再次加入一個有 150MB 可分配記憶體的叢集，然後檢查 Placement 事件。這一次 event 並沒有更新。

```
# oc describe placement demo -n ns1
...
Events:
  Type    Reason          Age   From                 Message
  ----    ------          ----  ----                 -------
  Normal  DecisionCreate  80s   placementController  Decision demo-decision-1 is created with placement demo in namespace ns1
  Normal  DecisionUpdate  80s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1
  Normal  ScoreUpdate     80s   placementController  cluster1:0 cluster2:100 cluster3:200
```

再次檢查 PlacementDecision，可以看到排程結果並沒有變化，固定在了 cluster2 和 cluster3。

```
# oc describe placementdecision demo-decision-1 -n ns1
...
Status:
  Decisions:
    Cluster Name:  cluster2
    Reason:        
    Cluster Name:  cluster3
    Reason:
```

在前面的三個示例中，我們展示了多個優選器是如何協同工作的，以及如何透過調整每個優選器的權重來影響最終決策。在使用中，你也可以按需求嘗試調整權重或更改已啟用的優選器。

## 總結

透過本文，你可以瞭解到如何在不同的應用場景下使用 Placement API。這篇文章解釋了什麼是 Placement 以及它如何和一些主流的開源專案配合使用。介紹了 Placement 如何選擇叢集，以及透過一些示例展示多個優選器是如何共同工作並做出排程決策的。在文章的最後，提供了一些示例來展示最佳實踐。歡迎隨時在 open-cluster-management-io GitHub 社群 **[7]** 中提出問題，或使用 Slack **[8]** 與我們聯絡，同時加入我們的 Google Groups 以訂閱我們的定期社群會議。

未來我們將在 OCM 裡看到更多結合 OCM 高階排程能力的其他高階功能模組，比如多叢集 Workload 排程/容災等等。

## 相關連結

[1] Open Cluster Management 0.6 釋出：

[](https://open-cluster-management.io/community/releases/)

<https:></https:>

[2] OCM 社群：

[](https://github.com/open-cluster-management-io/community/issue)

<https:>

[3] ManagedCluster 和 ManagedClusterSet：

[](https://open-cluster-management.io/concepts/managedcluster/)

<https:></https:>

[4] Placement：

[](https://open-cluster-management.io/concepts/placement/)

<https:></https:>

[5] PlacementSpec：

[](https://github.com/open-cluster-management-io/api/blob/main/cluster/v1alpha1/types.go)

<https:>

[6] 社群文件：

[](https://github.com/open-cluster-management-io/enhancements/blob/main/enhancements/sig-architecture/32-extensiblescheduling/32-extensiblescheduling.md)

<https:>

[7] open-cluster-management-io GitHub 社群：

[](https://github.com/open-cluster-management-io/community/issues)

<https:>

[8] Slack：

[](https://kubernetes.slack.com/archives/C01GE7YSUUF)

<https:>

參考：[](https://timewitch.net/post/2020-03-31-multicluster-workloads/)[](https://timewitch.net/post/2020-03-31-multicluster-workloads/)

[](https://timewitch.net/post/2020-03-31-multicluster-workloads/)[https://timewitch.net/post/2020-03-31-multicluster-workloads/](https://timewitch.net/post/2020-03-31-multicluster-workloads/)

點選“[**此處**](https://open-cluster-management.io/zh/)”，快速瀏覽 OpenClusterManagement 中文站點。</https:></https:></https:></https:></https:></none></none></none></none>

CNCF 沙箱專案 OCM Placement 多叢集排程指南

相關文章