k8s多集群分发方案karmada解析

导读：kubernetes已经是容器编排的业界标准，各个云厂商都提供了相关的集群托管服务，同时不少公司也存在自建集群。如何将应用发布到不同k8s集群，对跨多集群或者混合云的应用进行管理则是k8s中待解决的问题。本文会分析华为云开源的多集群解决方案-karmada。

背景

k8s官方宣称支持最大150000个pods，5000个node。但是现实生产环境中业务时常有超过该规模的述求，比如说大型电商如淘宝，拼多多，又比如AI和大数据处理的workflow。同时出于合作和业务述求，一家公司还有可能将业务部署到不同的云厂商，或者自建机房和公有云配合使用。因此k8s多集群方案也是云原生领域的一个热点。

目前主要的多集群问题有：

1. 集群运维。包括集群的加入，删除，集群内机器的运维，k8s社区有ClusterAPI项目屏蔽底层云厂商，以统一方式管理多集群。同时蚂蚁金服之前也有通过k8s on k8s的方案去管理node节点上的系统组件；
2. 多集群网络管理。解决集群间网络的连通性，例如multicluster-ingress解决多集群的ingress，以及istio，cilium等网络组件实现的multi cluster mesh解决跨集群的mesh网络管理。
3. 多集群对象分发。解决k8s中的对象，尤其是workload在多集群间分发，例如红帽领衔的kubefed v2，以及本文即将解析的karmada。

核心概念

Karmada是基于kubefed v2进行修改的一个项目，因此里面很多概念都是取自kubefed v2
。

relation.png

1. Resource Template。和我们平时使用k8s的对象例如Deployment，Secret，Configmap没有不同，但是需要我们在global集群进行创建和修改；
2. Propagation Policy。定义Resource Template需要被调度到那些集群，此概念和kubefed v2相同；
3. Resource Binding。即Resource Template根据Propagation Policy调度之后的结果，保存在ResourceBinding中；
4. Override Policy。由于我们可能需要在不同集群里面部署不同的版本，或者副本数，我们可以通过Override Policy对Resource Binding中的结果进行修改；
5. 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继承的概念：

1. PropagationPolicy用于定义对象分发的策略；
2. 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:

propagation.jpg

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"

则新的部署结果如下图：

override.jpg

处理流程分析

通过阅读Karmada的源码后，整理了整个的对象处理流程如下图所示

dataflow.jpg

1. 用户在global集群中创建对象；
2. Resource Detector会每30s去list集群中的所有资源，放到队列中；
3. Resource Detector会对队列中的每个对象查找匹配的PropagationPolicy，创建Binding；
4. 此时的Binding中没有targetCluster，而Karmada Scheduler会根据Cluster和PropagationPolicy计算调度结果，填入Binding的targetCluster；
5. BindingController会watch OverridePolicy和Binding，创建Work(每个cluster会有一个namespace)；
6. ExecutionControllerwatch到Work对象，提取spec.workload定义的对象，然后调用worker集群的client来创建和修改对象；
7. 而worker集群的Agent则同样会watch Work对象并同步Workload的状态到Work；

Karmada优点和缺点

优点

通过对Karmada的文档和源码分析，Karmada相对于kubefed v2的最大优点：完全兼容k8s的API。

应用从单集群扩展为多集群时，不需要修改源文件，仅需要添加多集群的manifest包括PropagationPolicy和OverridePolicy，这些文件完全可以由运维同学来添加。因此用户迁移和学习成本不大。

缺点

但是Karmada也有一些缺点：

1. 演进维护成本。由于karmada是基于k8s的控制组件做修改，如何保持与后续k8s新的对象和feature同步，也是一个挑战；
2. 所有workload的支持。笔者在调研karmada的时候，karmada还只支持deployment，并且在worker controller里面发现有一些细小逻辑在对不同workload做一些特殊处理，因此如果karmada支持的workload和对象越多，后续这种逻辑也会更多。如果不通读整个工程话，是挺容易产生bug的，后续维护也挺头痛；

总结

Karmada出发点是想让用户尽量不要修改原始的物料，来完成单集群到多集群的修改。但是本文也指出了Karmada的一些缺点(也是感谢评论区的指正)。同时社区也有一个竞品方案https://open-cluster-management.io/，但是整体开发进度没有karmada快，过段时间也会专门对比一下。