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

文章插图

方案二：ansible开发Operator

文章插图

方案三：golang和ansible混合开发Operator

文章插图
根据Karmada的实际生产部署调研情况和vivo自身的实践，可以总结如下：

要支持在K8s集群和不依赖K8s集群二进制部署。
支持外部独立的etcd集群部署或者对接已有的etcd集群。
Karmada集群具备迁移能力，如机房裁撤和机器故障等，就需要etcd集群管理有备份和恢复能力，如根据etcd备份数据快速在其它机房恢复集群。
需要支持第三方的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设计