导读：kubernetes已经是容器编排的业界标准，各个云厂商都提供了相关的集群托管服务，同时不少公司也存在自建集群。如何将应用发布到不同k8s集群，对跨多集群或者混合云的应用进行管理则是k8s中待解决的问题。本文会分析华为云开源的多集群解决方案-karmada。
背景
k8s官方宣称支持最大150000个pods，5000个node。但是现实生产环境中业务时常有超过该规模的述求，比如说大型电商如淘宝，拼多多，又比如AI和大数据处理的workflow。同时出于合作和业务述求，一家公司还有可能将业务部署到不同的云厂商，或者自建机房和公有云配合使用。因此k8s多集群方案也是云原生领域的一个热点。
目前主要的多集群问题有：
- 集群运维。包括集群的加入，删除，集群内机器的运维，k8s社区有ClusterAPI项目屏蔽底层云厂商，以统一方式管理多集群。同时蚂蚁金服之前也有通过k8s on k8s的方案去管理node节点上的系统组件；
- 多集群网络管理。解决集群间网络的连通性，例如multicluster-ingress解决多集群的ingress，以及istio，cilium等网络组件实现的multi cluster mesh解决跨集群的mesh网络管理。
- 多集群对象分发。解决k8s中的对象，尤其是workload在多集群间分发，例如红帽领衔的kubefed v2，以及本文即将解析的karmada。
核心概念
Karmada是基于kubefed v2进行修改的一个项目，因此里面很多概念都是取自kubefed v2
。
- Resource Template。和我们平时使用k8s的对象例如Deployment，Secret，Configmap没有不同，但是需要我们在global集群进行创建和修改；
- Propagation Policy。定义Resource Template需要被调度到那些集群，此概念和kubefed v2相同；
- Resource Binding。即Resource Template根据Propagation Policy调度之后的结果，保存在ResourceBinding中；
- Override Policy。由于我们可能需要在不同集群里面部署不同的版本，或者副本数，我们可以通过Override Policy对Resource Binding中的结果进行修改；
- Work。经过Override Policy的渲染，Karmada会产生Work对象，而Work对象所处的namespace跟调度的cluster对应，同时work中包含最终的对象的Spec和Status。对应的Execution Controller和Agent会不断Reconcile Work对象，即在子集群中创建和更新Work中的workload，并更新globa集群中Work的status。
接下来我们会通过官方的demo来体验一下使用。
Demo
PropagationPolicy和OverridePolicy都是从kubefed v2继承的概念：
- PropagationPolicy用于定义对象分发的策略；
- OverridePolicy用于按需修改不同集群内对象的spec；
这里直接用官方样例对Karmada的PropagationPolicy和OverridePolicy进行介绍。
PropagationPolicy
首先我们在global集群中部署一个nginx的应用Deployment：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
我们想要将这个deployment分发到cluster1和cluster2两个工作集群中，那么我们需要创建一个PropagationPolicy来声明Deployment的分发规则：
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
name: nginx-propagation
spec:
resourceSelectors:
- apiVersion: apps/v1
kind: Deployment
name: nginx
placement:
clusterAffinity:
clusterNames:
- cluster1
- cluster2
上面这个PropagationPolicy通过spec中的resourceSelectors声明作用的对象为nginx的Deployment，而placement指明分发规则为分发到cluster1和cluster2。因此调度结果如下所示，在cluser1和cluster2两个工作集群中都会创建这个nginx的Deployment:
OverridePolicy
没有OverridePolicy，则worker集群中的deployment和global的deployment的spec相同，但是我们有可能是要针对worker集群的不同或者业务需求修改内容。
比如现在我们修改cluster1中的deployment的image为nginx:test，用来做一个灰度发布。则我们可以创建一个如下的OverridePolicy：
apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
metadata:
name: nginx-propagation
spec:
resourceSelectors:
- apiVersion: apps/v1
kind: Deployment
name: nginx
targetCluster:
clusterNames:
- cluster1
overriders:
plaintext:
- path: "/spec/template/spec/containers/0/image"
operator: replace
value: "nginx:test"
则新的部署结果如下图：
处理流程分析
通过阅读Karmada的源码后，整理了整个的对象处理流程如下图所示
- 用户在global集群中创建对象；
- Resource Detector会每30s去list集群中的所有资源，放到队列中；
-
Resource Detector会对队列中的每个对象查找匹配的
PropagationPolicy，创建Binding； - 此时的
Binding中没有targetCluster，而Karmada Scheduler会根据Cluster和PropagationPolicy计算调度结果，填入Binding的targetCluster； -
BindingController会watch
OverridePolicy和Binding，创建Work(每个cluster会有一个namespace)； -
ExecutionControllerwatch到
Work对象，提取spec.workload定义的对象，然后调用worker集群的client来创建和修改对象； - 而worker集群的Agent则同样会watch
Work对象并同步Workload的状态到Work；
Karmada优点和缺点
优点
通过对Karmada的文档和源码分析，Karmada相对于kubefed v2的最大优点：完全兼容k8s的API。
应用从单集群扩展为多集群时，不需要修改源文件，仅需要添加多集群的manifest包括PropagationPolicy和OverridePolicy，这些文件完全可以由运维同学来添加。因此用户迁移和学习成本不大。
缺点
但是Karmada也有一些缺点：
- 演进维护成本。由于karmada是基于k8s的控制组件做修改，如何保持与后续k8s新的对象和feature同步，也是一个挑战；
- 所有workload的支持。笔者在调研karmada的时候，karmada还只支持deployment，并且在worker controller里面发现有一些细小逻辑在对不同workload做一些特殊处理，因此如果karmada支持的workload和对象越多，后续这种逻辑也会更多。如果不通读整个工程话，是挺容易产生bug的，后续维护也挺头痛；
总结
Karmada出发点是想让用户尽量不要修改原始的物料，来完成单集群到多集群的修改。但是本文也指出了Karmada的一些缺点(也是感谢评论区的指正)。同时社区也有一个竞品方案https://open-cluster-management.io/，但是整体开发进度没有karmada快，过段时间也会专门对比一下。
