作者:
邱见|红帽资深软件工程师,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 将作为或许的选项。
以上每个字段的界说都在调度中发挥着效果。如下是一个典型的调度进程:
-
调度结构首先从 clusterSets 中界说的 ManagedClusterSet 中挑选出可用的 ManagedCluster。
-
过滤器插件 (filter plugin) 经过预选战略 predicates 中界说的标签 (label) 和声明 (claim) 挑选器进一步挑选 ManagedCluster。
-
在优选战略 prioritizerPolicy 启用的优选器插件 (prioritizer plugin) 会为每个挑选后的 ManagedCluster 打一个分数,而且按总分从高到低确定优先级。
-
调度结构会挑选前 k 个 ManagedCluster,并把这些集群列在 PlacementDecision 中。k 的值是在 numberOfClusters 界说的集群数量。
假如将以上步骤对应的上述的比方中,调度进程如下:
- 调度结构首先挑选 ManagedClusterSet clusterset1 和 clusterset2 中的集群作为可用的 ManagedCluster。
- 过滤器插件 (filter plugin) 挑选出带有标签 (label)vendor=OpenShift 的 ManagedCluster。
- 优选器插件 (prioritizer plugin)ResourceAllocatableMemory 和 Steady 为每一个挑选的 ManagedCluster 打分。当装备了优选战略 AddOn,Placement 会测验取得集群对应的第三方资源供给的分数 cpuratio。并用如下公式计算每个 ManagedCluster 的总分:
1(ResourceAllocatableMemory 的默许权重) * ResourceAllocatableMemory 的打分 + 3(Steady 的权重) * Steady 的打分 + 1(AddOn 的默许权重) * cpuratio(AddOn 的分数)
- 调度结构依照每个 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 发布:
open-cluster-management.io/community/r…
[2] OCM 社区:
github.com/open-cluste…
[3] ManagedCluster 和 ManagedClusterSet:
open-cluster-management.io/concepts/ma…
[4] Placement:
open-cluster-management.io/concepts/pl…
[5] PlacementSpec:
github.com/open-cluste…
[6] 社区文档:
github.com/open-cluste…
[7] open-cluster-management-io GitHub 社区:
github.com/open-cluste…
[8] Slack:
kubernetes.slack.com/archives/C0…
参阅:
https://timewitch.net/post/2020-03-31-multicluster-workloads/
点击“此处”,快速浏览 OpenClusterManagement 中文站点。