DaoCloud道客：云原生多云应用利器-Karmada控制器

在上一篇《云原生多云应用利器– Karmada 总览篇》中已经介绍了多云的相关简介的内容和架构。接下来，在这一篇中来一起看看 Karmada 中有哪些 Controllers 来协调完成多云的控制逻辑。

Controller (控制器) 在 Kubernetes 中是逻辑能力的主要体现所在，根据资源对象的状态来完成调和工作，让资源对象逐步接近期待的状态，这个就是 Kubernetes 的申明式特性。

在 Karmada 中，同样需要对 Karmada 自己的资源对象，实现对应的申明式特性，这就需要实现对应的 Controller。在Karmada 中目前的版本中有 11 个 Controllers，接下来就从每一个控制器所负责的资源对象，以及原理来分析一下，在 Karmada 中是怎样完成多云能力的。

Karmada Controllers一览表及原理分析

01 Cluster Controller

cluster controller 主要就是处理 Cluster 资源对象的逻辑，负责处理 Cluster 对应需要的关联资源。

02 Cluster status controller:

cluster status controller 主要就是处理 cluster status 资源对象的逻辑，用来收集 Cluster 的状态，保存到 Cluster 的 status 字段中，同步上报到 Karmada 的控制平面中。

03 namespace sync controller:

namespace sync controller 主要就是处理 namespace 资源对象的逻辑，负责将 Karmada 控制平面创建的 namespace 在集群中同步创建出来。

04 Resourse Template controller:

detector 模块中包含了通用 controller 负责 resource template 的 Kubernetes 资源对象的调和处理逻辑，以及匹配 PropagationPolicy。主要就是处理 PropagationPolicy 资源对象的逻辑，来派生出资源对象对应的 ResourceBinding 对象。

相关资源对象：PropagationPolicy， Kubernetes 支持的所有的资源对象 (包括 CRD)

定义处理 PropagationPolicy / ClusterPropagationPolicy 的 informer，event handler，以及对应的 reconciler 方法。
定义处理 ResourceBinding / ClusterResourceBinding 的 informer，event handler，以及对应的 reconciler 方法。
定义处理所有原生 Kubernetes 资源对象的 informer，event handler，以及对应的 reconciler 方法，然后为其创建对应的 ResourceBinding 对象用于调度。
根据 Kubernetes 的对象定义以及 PropagationPolicy 构建 ResourceBinding 对象，同时这个 ResourceBinding 的 OwnerReferences 设置了这个 Kubernetes 的对象，这样就会在删除 Kubernetes 对象的时候删除这个 ResourceBinding，这个也是目前 ResourceBinding 会被删除的唯一逻辑了。
所以虽然 ResourceBinding 是因为 PropagationPolicy 的创建而被派生出来，但是不会因为 PropagationPolicy 的删除而删除。
在删除 PropagationPolicy 删除的时候，只会去除 PropagationPolicy 和 Kubernetes 对象的关系，这个关系体现在，Kubernetes object 会在匹配到 PropagationPolicy 的时候在自己的 label 上增加 PropagationPolicy 相关的 label。
ResourceBinding 中不会包含 Kubernetes 资源对象的详细信息，只会包含类型，namespace，name，版本，副本数，cpu/memory 请求，节点亲和性，真正详细的 Kubernetes 对象的处理是在 controller 的syncbinding() 方法中完成，其中是通过workload, err := helper.FetchWorkload (c.DynamicClient,c.InformerManager,c.RESTMapper, binding.Spec.Resource) 去拿到真正的 Kubernetes 资源对象的定义的。
每隔 30s 去发现新的 Kubernetes 的资源对象类型，只要这些资源对象支持 list，watch，delete 方法，当然也包括 crd 类型。

05 Binding controller:

binding controller 主要就是处理 ResourceBinding 资源对象的增删改逻辑，ResourceBinding 的调和能力是派生出 work 对象，work 对象是和特定集群关联的。一个 work 只能属于一个集群，代表一个集群的资源对象的模型封装。

相关资源对象：ResourceBinding 和 ClusterResourceBinding

负责 ResourceBinding 的处理，根据 binding 去创建对应的 Work 对象到集群对应的 execution space 中。
在生成 Work 的时候,会处理 OverridePolicy，将需要覆盖的数据更新到 Work 对应的 manifest 中。目前支持的 override 的方式主要是 4 种，包括：PlaintextOverrider，mageOverrider，CommandOverrider，ArgsOverrider。

apiVersion: policy.karmada.io/v1alpha1 kind: OverridePolicy metadata: name: nginx-propagation spec: resourceselectors: 一 apiVersion: apps/v1 kind: Deployment name: nginx targetcluster: clusterNames: -10-23-20-93 overriders: plaintext: 一 path: "/spec/template/spec/containers/O/image"  operator: replace value: "nginx:test"

根据调度器计算好的每一个集群负责的副本数，如果调度器计算出来的所有集群的对应的副本数是 0，说明没有找合适的集群，就用 ReplicaSchedulingPolicy 根据权重去计算每一个集群应该负责的副本数，这个 ReplicaSchedulingPolicy 的计算副本分配的方式是用 static weight。
收集每一个 binding 的状态，一个 binding 会包含多个 Work，因为同一个资源对象，在每一个集群中就需要一个 Work，所有 binding 的状态是所有工作集群中 Work 的状态的汇总，汇总之后将这个状态设置到 binding 的 status 中去。

备注：原理图参见第 4 部分的图

06 execution controller:

execution controller 主要就是处理 Work 资源对象的增删改逻辑，用于处理 Work，将 Work 负责的 Kubernetes 资源对象在对应的集群上创建出来。

07 work status controller:

work status controller 主要就是处理 Work 资源对象的状态逻辑，负责收集 Work 的状态，也就是 Work 对应的资源对象的状态，只是这个状态是保存在 Work 的 status 字段里的。

相关资源对象：Work，以及 Work 负责的资源对象。

watch Work 对象为指定计算集群包含的所有的 Work 对象所负责的资源对象的类型创建对应的 informer 对象，同时调用 informer 的 WaitForCacheSync，当 WaitForCacheSync 结束了之后，也就是 list 结束了，接下来就是 watch 的任务了。这个就是 list and watch 的核心机制。
在 watch 所有 Work 负责的资源对象的时候，设置了一个事件处理器，这个事情处理器会负责处理所有相关资源对象的 Add，Update，Delete 事件。这些事件存放在 queue 中。
启动一个异步的 AsyncWorker, 设置一定的 WorkerNumber 数量的 goroutines 去处理 queue 里的数据，这里的数据是带有集群信息的 fedkey。
从 queue 中获取 fedkey，判断这个 fedkey 的对应的集群中的资源对象，如果这个 Work 负责的资源对象在工作集群中被非法删除了，会重新在工作集群中创建出对应的资源对象。
从 queue 中获取 fedkey，判断这个 fedkey 的对应的集群中的资源对象，如果这个 Work 负责的资源对象被修改了之后是不是修改被修改回去。如果是的话，会重新 sync 回资源对象，防止直接从工作集群中直接修改资源对象。
收集 Work 对象对应的资源对象在 Worload 集群中的运行状态，然后更新到到控制平面的 Work 的 status 中。
watch Karmada 控制平面的 execution namespace 中的所有 Work 对象，当有新的 Work 对象被创建了之后会在对应的工作集群中创建 Work 负责的资源对象。

08 serviceexport controller:

serviceexport controller 主要就是处理 serviceexport 资源对象的状态逻辑,将需要被其它集群发现的服务暴露出来。

09 endpointslice controller:

endpointslice controller 主要根据 serviceexport 资源对象对应到处的 Service，Service 对应的 endpointslice 上报到 Karmada 的控制面。

相关资源对象：EndpointSlice 相关的 Work

负责将 work 中的 manifest 是 EndpointSlice 的 work 中的 EndpointSlice 对象，在 Karmada 控制平面中创建对应的 EndpointSlice 的对象。
其中 Karmada 控制平面中的 EndpointSlice 的 namespace 就是和 work 中 manifest 中的 EndpointSlice 的 namespace 一样。但是 Karmada 控制平面中的 EndpointSlice 的 name 不一样，格式为：“imported-<cluster name>-<endpointslice name>”。

备注：原理图参见第 8 部分的图

10 serviceimport controller:

serviceimport controller 主要负责根据 ServiceExport 暴露出来的 Service，在自己负责的集群中创建对应的 service，注意 service 的名称不是完全一样的，同时在自己负责的集群中也创建对应的 EndpointSlice，这个 EndpointSlice 的数据就是来源于 EndpointSlice controller 中上报到 karmada 控制平面的 EndpointSlice 对象，具体是通过在 karmada-webhook 中给 ServiceImport 的 PropagationPolicy 中增加了 EndpointSlice 的下发能力。

11 hpa controller:

hpa controller 主要负责将 Karmada 控制面中创建的 HPA 对象通过创建 Work 的方式下发到对应的集群中。

12 「DaoCloud 道客」贡献参与

目前「DaoCloud 道客」在 Karmada 项目中，主要参与调度模块和部署模块的设计开发，也参与相关 bug 的修复，完成了非 root 权限快速安装karmada 的功能开发，对优先级调度和抢占特性、插件管理特性等方面，也在持续的关注和跟进。

图注：已提交的PR

图注：跟进的项目

想了解更多，您可以加入交流群：http://blog.daocloud.io/wp-content/uploads/kefu.jpeg

DaoCloud 公司简介:「DaoCloud 道客」云原生领域的创新领导者，成立于 2014 年底，拥有自主知识产权的核心技术，致力于打造开放的云原生操作系统为企业数字化转型赋能。产品能力覆盖云原生应用的开发、交付、运维全生命周期，并提供公有云、私有云和混合云等多种交付方式。成立迄今，公司已在金融科技、先进制造、智能汽车、零售网点、城市大脑等多个领域深耕，标杆客户包括交通银行、浦发银行、上汽集团、东风汽车、海尔集团、屈臣氏、金拱门（麦当劳）等。目前，公司已完成了 D 轮超亿元融资，被誉为科技领域准独角兽企业。公司在北京、武汉、深圳、成都设立多家分公司及合资公司，总员工人数超过 350 人，是上海市高新技术企业、上海市“科技小巨人”企业和上海市“专精特新”企业，并入选了科创板培育企业名单。