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

简介:在这篇文章中,将介绍 Placement 如何选择到所需的集群,Placement 可以提供的调度功能,以及一些场景下的最佳实践,使用者可以参考示例来编写符合自己要求的 Placement。其他一些高级调度功能,如支持污点 (taints) 和容忍 (tolerations),以及拓扑选择 (spread),正在 OCM 社区讨论中。

作者:

邱见|红帽资深软件工程师,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-placementlabelSelector:matchLabels:cluster.open-cluster-management.io/placement: local-clusterrequeueAfterSeconds: 30template:
…apiVersion: v1
kind: ConfigMap
metadata:name: ocm-placement
data:apiVersion: cluster.open-cluster-management.io/v1alpha1kind: placementdecisionsstatusListKey: decisionsmatchKey: clusterNameapiVersion: cluster.open-cluster-management.io/v1alpha1
kind: PlacementDecision
metadata:labels:cluster.open-cluster-management.io/placement: local-clustername: local-cluster-decision-1
status:decisions:- clusterName: cluster1reason: ""- clusterName: cluster2reason: ""

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: placementnamespace: ns1
spec:numberOfClusters: 4clusterSets:- clusterset1- clusterset2predicates:- requiredClusterSelector:labelSelector:matchLabels:vendor: OpenShiftprioritizerPolicy:mode: Exactconfigurations:- scoreCoordinate:builtIn: ResourceAllocatableMemory- scoreCoordinate:builtIn: Steadyweight: 3- scoreCoordinate:type: AddOnaddOn:resourceName: defaultscoreName: 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。
     
  2. 过滤器插件 (filter plugin) 筛选出带有标签 (label)vendor=OpenShift 的 ManagedCluster。
     
  3. 优选器插件 (prioritizer plugin)ResourceAllocatableMemory 和 Steady 为每一个筛选的 ManagedCluster 打分。当配置了优选策略 AddOn,Placement 会尝试获得集群对应的第三方资源提供的分数 cpuratio。并用如下公式计算每个 ManagedCluster 的总分:

1(ResourceAllocatableMemory 的默认权重) * ResourceAllocatableMemory 的打分 + 3(Steady 的权重) * Steady 的打分 + 1(AddOn 的默认权重) * cpuratio(AddOn 的分数)

  1. 调度框架按照每个 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: demonamespace: ns1
spec:numberOfClusters: 2prioritizerPolicy: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:14ZMessage:                    All cluster decisions scheduledReason:                     AllDecisionsScheduledStatus:                     TrueType:                       PlacementSatisfiedNumber 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 ns1Normal  DecisionUpdate  10s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1Normal  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:  cluster2Reason:        Cluster Name:  cluster3Reason:        
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 ns1Normal  DecisionUpdate  100s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1Normal  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 ns1Normal  DecisionUpdate  2m10s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1Normal  ScoreUpdate     2m10s   placementController  cluster1:0 cluster2:100 cluster3:200Normal  DecisionUpdate  3s      placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1Normal  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:  cluster3Reason:        Cluster Name:  cluster4Reason:

在上面这个例子中,当资源只发生了少许变化时,调度结果并不会被影响。而当资源发生比较大的变化时,变化会立刻反应在调度结果中。这样便引发出如下 2 个挑战:

  • 如果希望调度结果对资源变化保持敏感,应该怎么做?
  • 如果希望调度结果保持稳定,忽略资源的变化,应该怎么做?

还记得我们在 prioritizerPolicy 中有 4 个优选器并且可以调整他们的权重吗?我们可以通过修改 prioritizerPolicy 的配置来解决上面两个问题。

示例 2:选择具有最大可分配内存的群集,并使 Placement 对资源变化保持敏感。

为了使调度结果对资源的变化敏感,这次我们显式设置了优选器 ResourceAllocatableMemory,权重为 3。

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: Placement
metadata:name: placement7namespace: ns1
spec:numberOfClusters: 2prioritizerPolicy:configurations:- scoreCoordinate:builtIn: ResourceAllocatableMemoryweight: 3

当 Placement 创建好之后,让我们通过 oc describe 命令来检查 Placement 和 PlacementDecision 的结果。

# oc describe placement demo -n ns1
...
Status:Conditions:Last Transition Time:       2021-11-09T08:58:40ZMessage:                    All cluster decisions scheduledReason:                     AllDecisionsScheduledStatus:                     TrueType:                       PlacementSatisfiedNumber 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 ns1Normal  DecisionUpdate  35s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1Normal  ScoreUpdate     35s   placementController  cluster1:-200 cluster2:100 cluster3:400
# oc describe placementdecision demo-decision-1 -n ns1
...
Status:Decisions:Cluster Name:  cluster2Reason:        Cluster Name:  cluster3Reason:

初始的调度结果为 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 ns1Normal  DecisionUpdate  3m1s  placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1Normal  ScoreUpdate     3m1s  placementController  cluster1:-200 cluster2:100 cluster3:400Normal  DecisionUpdate  2s    placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1Normal  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:  cluster3Reason:        Cluster Name:  cluster4Reason:

示例 3:选择具有最大可分配内存的集群并稳定调度结果。

为了使调度结果保持稳定,这次我们显式设置了优选器 Steady,并且设置权重为 3。

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

Placement 创建好之后,再次通过 oc describe 命令来检查 Placement 和 PlacementDecision 的结果。

# oc describe placement demo -n ns1
...
Status:Conditions:Last Transition Time:       2021-11-09T09:05:36ZMessage:                    All cluster decisions scheduledReason:                     AllDecisionsScheduledStatus:                     TrueType:                       PlacementSatisfiedNumber 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 ns1Normal  DecisionUpdate  15s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1Normal  ScoreUpdate     15s   placementController  cluster1:0 cluster2:100 cluster3:200
# oc describe placementdecision demo-decision-1 -n ns1
...
Status:Decisions:Cluster Name:  cluster2Reason:        Cluster Name:  cluster3Reason:

初始的调度结果为 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 ns1Normal  DecisionUpdate  80s   placementController  Decision demo-decision-1 is updated with placement demo in namespace ns1Normal  ScoreUpdate     80s   placementController  cluster1:0 cluster2:100 cluster3:200

再次检查 PlacementDecision,可以看到调度结果并没有变化,固定在了 cluster2 和 cluster3。

# oc describe placementdecision demo-decision-1 -n ns1
...
Status:Decisions:Cluster Name:  cluster2Reason:        Cluster Name:  cluster3Reason:

在前面的三个示例中,我们展示了多个优选器是如何协同工作的,以及如何通过调整每个优选器的权重来影响最终决策。在使用中,你也可以按需求尝试调整权重或更改已启用的优选器。

总结

通过本文,你可以了解到如何在不同的应用场景下使用 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

[2] OCM 社区:

https://github.com/open-cluster-management-io/community/issue

[3] ManagedCluster 和 ManagedClusterSet:

Open Cluster Management

[4] Placement:

Open Cluster Management

[5] PlacementSpec:

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

[6] 社区文档:

enhancements/32-extensiblescheduling.md at main · open-cluster-management-io/enhancements · GitHub

[7] open-cluster-management-io GitHub 社区:

https://github.com/open-cluster-management-io/community/issues

[8] Slack:

Slack

参考:

A Model For Multicluster Workloads (In Kubernetes And Beyond) | Vallery Lancey

原文链接

本文为阿里云原创内容,未经允许不得转载。 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/510993.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

02 解构赋值

解构赋值 1.1 什么是解构赋值 允许按照一定模式&#xff0c;从数组和对象中提取值&#xff0c;对变量进行赋值&#xff0c;这被称为解构 只要某种数据结构具有 Iterator 接口&#xff0c;都可以采用数组形式的解构赋值 1.2 数组解构赋值和对象解构赋值的区别 数组的元素是按次…

如何帮助业务丝滑配置?阿里巴巴用了 11 年的“功能开关” 是什么?

简介&#xff1a;AHAS 功能开关是一个轻量级的动态配置框架&#xff0c;通过功能开关可以动态管理代码中的配置项&#xff0c;根据需求为某个应用开启或关闭部分功能&#xff0c;或设置某个性能指标的阈值。功能开关通常用于设置黑白名单、运行时动态调整日志级别、降级业务功能…

摆脱 AI 生产“小作坊”:如何基于 Kubernetes 构建云原生 AI 平台

简介&#xff1a;本文将介绍和梳理我们对云原生 AI 这个新领域的思考和定位&#xff0c;介绍云原生 AI 套件产品的核心场景、架构和主要能力。 作者&#xff1a;张凯 前言 云原生&#xff08;Cloud Native&#xff09;[1]是云计算领域过去 5 年发展最快、关注度最高的方向之一…

Node 之父斥责 Oracle:你们也不用,那请交出 JavaScript 商标!

整理 | 苏宓出品 | CSDN&#xff08;ID&#xff1a;CSDNnews&#xff09;也许 13 年前&#xff0c;Oracle 以 74 亿美元收购 Sun Microsystems 公司时&#xff0c;也不会想到自己后续要牵扯到诸多的版权诉讼与投诉的漩涡之中。众所周知&#xff0c;Oracle 在收购 Sun 之后&…

mobx的使用

mobx的使用 1、API mobx-react Provider 包裹根组件&#xff0c;用于传递数据observer 组件变为响应式inject 接收mobx实例(用于类组件)MobXProviderContext mobx observable 声明变量action 声明函数用于修改observable 的值makeObservable 更新状态 2、安装 yarn add mo…

OPLG:新一代云原生可观测最佳实践

简介&#xff1a;OPLG 体系拥有成熟且富有活力的开源社区生态&#xff0c;同时也经过了大量企业生产环境的实践检验&#xff0c;是当下建设新一代云原生统一可观测平台的热门选择。但是&#xff0c;OPLG 只是提供了一个技术体系&#xff0c;如何灵活运用&#xff0c;解决实际问…

EventBridge 集成云服务实践

简介&#xff1a;本篇文章主要向大家分享了通过 EventBridge 如何集成云产品事件源&#xff0c;如何集成云产品事件目标以及通过事件流如何集成消息产品。 作者&#xff1a;李凯&#xff08;凯易&#xff09; EvenBridge 集成概述 EventBridge 是阿里云所推出了一款无服务器…

前端性能——数据持久化

如何实现数据持久化 一般情况下&#xff0c;借用本地存储用的比较多&#xff0c;或者一些插件&#xff0c;如vue的keep-alive&#xff0c;配合redux使用的persist 为什么需要数据持久化 1、减少发起请求的次数&#xff0c;从而提高性能。 场景&#xff1a;比如一个网站&…

云原生微服务的下一站,微服务引擎 MSE 升级

简介&#xff1a;管好微服务&#xff0c;成为云原生时代的新难题。 管好微服务&#xff0c;成为云原生时代的新难题。 从建好微服务到管好微服务&#xff0c;差的虽是一个字&#xff0c;连接起两边的却需要大量的微服务落地经验。因为软件架构的核心挑战是解决业务快速增长带…

火爆全网的“数字人”,到底是个啥?

作者 | 小枣君来源 | 鲜枣课堂庄子他老人家说过&#xff1a;“人生&#xff0c;就是一场游戏。”对于这场游戏&#xff0c;有些人玩得很嗨&#xff0c;到了结尾不肯退场&#xff0c;总希望无限期玩下去。例如秦始皇&#xff0c;总想着灵丹妙药、长生不死。还有些人呢&#xff0…

阿里云RemoteShuffleService新功能:AQE和流控

简介&#xff1a;阿里云EMR自2020年推出Remote Shuffle Service(RSS)以来&#xff0c;帮助了诸多客户解决Spark作业的性能、稳定性问题&#xff0c;并使得存算分离架构得以实施。为了更方便大家使用和扩展&#xff0c;RSS在2022年初开源&#xff0c;欢迎各路开发者共建。本文将…

react如何在父组件中调用子组件事件

父组件是如何使用子组件的事件的&#xff0c;下边数值累加的例子 类组件 将子组件的this传到父组件&#xff0c;给父组件添加一个属性&#xff0c;值为this&#xff0c;之后就可以通过父组件的属性调用子组件的事件了 import React,{Component} from react;// 这是子组件 clas…

OpenSergo 正式开源,多家厂商共建微服务治理规范和实现

简介 OpenSergo&#xff0c;Open 是开放的意思&#xff0c;Sergo 则是取了服务治理两个英文单词 Service Governance 的前部分字母 Ser 和 Go&#xff0c;合起来即是一个开放的服务治理项目。 该项目由阿里云、bilibili、字节跳动&#xff0c;以及 Spring Cloud Alibaba、Nacos…

Linux中常见的网络端口号

在使用计算机或智能手机时&#xff0c;我们使用各种硬件端口&#xff0c;如用于音频、HDMI、Type-c 等的 3.5mm 端口&#xff0c;其用于与硬件外围设备通信。同样&#xff0c;网络端口可以让我们在一台计算机上访问各种网络服务来达到通信的目的。因此&#xff0c;端口被认为是…

如何在云原生混部场景下利用资源配额高效分配集群资源?

简介&#xff1a;由于混部是一个复杂的技术及运维体系&#xff0c;包括 K8s 调度、OS 隔离、可观测性等等各种技术&#xff0c;之前的一篇文章《历经 7 年双 11 实战&#xff0c;阿里巴巴是如何定义云原生混部调度优先级及服务质量的&#xff1f;》&#xff0c;主要聚焦在调度优…

前端面试题网址合辑

八个笔试&面试仓库 1.Front-end Developer Interview Questions网址&#xff1a;https://h5bp.org/Front-end-Developer-Interview-Questions/ 2.CS-Interview-knowledge-Map 网址&#xff1a;https://github.com/InterviewMap/CS-Interview-Knowledge-Map 3.Daily-Questio…

稳定性与高可用保障的工作思路

简介&#xff1a;稳定性与高可用性是老生常谈的两个词。凭借经验和感受我们知道&#xff0c;提高系统的这两项指标&#xff0c;系统会更加健康&#xff0c;产品也会有更好的用户体验。但是如果要给稳定性和高可用性下一个定义该如何表述&#xff1f;稳定性和高可用性这二者又有…

招商银行 KubeVela 离线部署实践

简介&#xff1a;本文将以 KubeVela v1.2.5 版本为例&#xff0c;介绍招商银行 KubeVela 的离线部署实践&#xff0c;来帮助其他用户在离线环境中更便捷的完成 KubeVela 的部署。 招商银行云平台开发团队自 2021 年开始接触 KubeVela&#xff0c;并探索 KubeVela 在招商银行云…

腾讯云数据库自研内核全新升级 新架构比原先性能提升20%

9月16日&#xff0c;腾讯云数据库自研内核TXSQL完成了全新升级。搭载了新一代内核的云数据库在性能上较之前提升超过20%&#xff0c;延迟降低80%。目前&#xff0c;新一代内核TXSQL已应用于腾讯云数据库MySQL、分布式数据库TDSQL、云原生数据库TDSQL-C等多款主流云数据库产品中…

系统性能分析从入门到进阶

简介&#xff1a;本文以系统为中心, 结合日常工作和用例, 由浅入深地介绍了性能分析的一些方法和体会, 希望对想了解系统性能分析的同学有所帮助。 作者 | 勿非 本文以系统为中心, 结合日常工作和用例, 由浅入深地介绍了性能分析的一些方法和体会, 希望对想了解系统性能分析的…