多云容器编排 Karmada-Operator 实践( 二 ) _生活百科

需要支持第三方的vip给Karmada-apiserver提供负载均衡，目前vivo都是基于外部vip，并提供了域名。没有使用K8s的service给Karmada-apiserver提供负载均衡。

Karmada控制平面一键部署和member集群的自动化注册和注销。也需要获取member集群的kubeconfig，pull模式也需要在member集群部署Karmada-agent 。

Karmada集群的addons插件安装，如istio、anp、第三方的crd等安装，需要在Karmada的控制平面、host主机集群，甚至需要在member集群上进行配置。

提供api能力，实现可视化部署。

针对Karmada单个组件的单独升级和全量升级。

支持在offline和离线模式。

面对Karmada如此复杂的条件限制，我们再来分析下上面3个方案谁可能比较合适。
方案一，基于go开发的Operator，比较适合基于K8s集群的有状态服务管理，如etcd，数据库等，比较成熟的有etcd-Operator 。Karmada涉及到不依赖K8s集群二进制部署、外部etcd、member集群的注册、注销和插件安装，不能很好的支持或者需要增加开发量。
方案二，基于ansible开发的Operator，既可以基于K8s集群的对状态服务管理，也可以脱离K8s集群对如不依赖K8s集群二进制部署、外部etcd、member集群的注册、注销和插件安装。这里主要通过ansible 的ssh登录能力和K8s模块管理，通过调研我们也发现90%以上的用户可以提供ssh登录。
方案三，基于go+ansible的混合的Operator，读者可以阅读vivo开发的Kubernetes-Operator，就是基于这种方案。方案三具备方案二的所有能力，因为底层都是通过ansible去执行。
首先我们排除了方案一，对于方案二和方案三，本人也纠结了很长是时间，最终我们选择了方案二。主要原因如下：

Operator SDK ansible已具备了和Operator SDK go相等的能力，并提供K8s、K8s_status模块、相似的webhook功能去对k8s的资源管理，以及reconciliation的能力。
符合目前Karmada实际生产部署的需求。
简单易学，只要知道ansbile的jinja模版、和K8s相同的yaml文件。你只需要编写ansible task，开箱即用，reconciliation由Operator SDK 解决。
对于常用ansible的人比较友好，不需要写golang代码。
扩展能力强，用户可自定义插件。管理端也支持local、ssh、zeromq三种方式连接。local模式可以直接对接K8s接口， ssh模式可以登录执行脚本。可以很好的混合使用，解决我们当前的需求。
Karmada运维操作相对K8s要简单，不需要复杂的crd定义，ansible需要解析少量vars去执行playbook就行。golang+ansible模式比较适合复杂CRD定义和业务逻辑复杂的系统。

2.3 API设计

文章插图
如上图所示，我们只需要执行Operator-SDK create api命令，就可以创建 KarmadaDeployment的CRD，然后就可以定义KarmadaDeployment的API 。在watches.yaml里实现Reconcile的业务逻辑。

文章插图
这里主要定义KarmadaDeployment、EtcdBackup和EtcdRestore个资源，分别用于Karmada的部署，和etcd的数据备份和恢复。ansible Operator会根据spec里定义解析成ansible的vars 。status将通过 ansible runner 输出为用户自定义的状态。也可以通过ansible的k8s_status更新KarmadaDeployment的状态。当前主要考虑的是在K8s运行Karmada ，后面会添加二进制部署模式，当前的CR没有涉及。
2.4 架构设计

文章插图
如图所示Karmada Operator提供了容器化和二进制集群部署设计，其中Karmada的容器化部署不需要执行ssh登录，只需通过K8s和k8s_status就可以完成karmada控制面的管控。Karmada的二进制部署主要通过ssh登录完成Karmada控制平面的管控。member集群的join和unjoin需要提前提供member集群的kubeconfig文件，也可以设置member的登录权限操作，需要在CR里定义member集群的用户和密钥。
执行流程如下。