CNCF 沙箱项目 OCM Placement 多集群调度指南

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: