作者：vivo 互联网服务器团队-Zhang Rong

Karmada作为开源的云原生多云容器编排我的项目，吸引了泛滥企业独特参加我的项目开发，并运行于生产环境中。同时多云也逐渐成为数据中心建设的基础架构，多区域容灾与多活、大规模多集群治理、跨云弹性与迁徙等场景推动云原生多云相干技术的疾速倒退。

一、 背景

随着vivo业务一直迁徙到k8s上，集群规模和集群的数量快速增长，运维难度也急剧减少。为了构建多集群技术，咱们也自研了多集群治理，但无奈解决咱们遇到的更多的问题。起初开始对社区相干我的项目做了粗疏的调研和测试，咱们最终抉择了Karmada。

次要起因如下：

  • 具备对多套K8s集群的对立治理能力，业务通过服务维度去治理资源，升高容器平台的治理难度。
  • 跨集群的弹性伸缩和调度能力，实现跨集群的资源正当利用，从而晋升资源利用率并节约老本。
  • Karmada齐全应用了K8s原生的API，革新成本低。
  • 容灾，Karmada管制立体与member集群解藕，集群异样时反对资源重新分配。
  • 可扩展性，如能够增加自研的调度插件和增加自研Openkruise解释器插件等。

在咱们摸索怎么应用Karmada的同时，咱们也遇到了Karmada本身运维的问题。

社区部署工具较多，须要用户本人抉择。以后用户部署形式如下：

  • Karmadactl
  • Karmada charts
  • 二进制部署
  • hack目录下脚本

对于下面的几种工具，在Karmada的社区发展了问卷调研，并生成了统计报告。

次要总结如下：

  • 社区部署工具较多，须要用户本人抉择。
  • 部署脚本也存在缺点，须要用户本人解决，github上对于这方面的发问较多。
  • 黑屏化操作，没有提供k8s api操作，用户难以产品化，咱们次要冀望对接咱们的容器平台，实现可视化装置。
  • 短少CI测试和部署工具的公布打算。
  • etcd集群短少生产环境的要害性能点，如etcd的高可用、定期备份和复原。
  • 须要装置很多依赖插件，波及到Karmada管制立体、Karmada的host集群和member集群。
  • 短少一键部署和配置繁琐等痛点。

针对以上问题，本文将分享Karmada-Operator的vivo实际，包含Operator的计划抉择、API、架构设计和CI构建等。

二、Karmada-Operator的落地实际

2.1 Operator SDK介绍

Operator Framework 是一个开源工具包，用于以无效、自动化且可扩大的形式治理 Kubernetes 原生应用程序，即 Operator。Operator 利用 Kubernetes 的可扩展性来展示云服务的自动化劣势，如置备、扩大以及备份和复原，同时可能在 Kubernetes 可运行的任何中央运行。

Operator 有助于简化对 Kubernetes 上的简单、有状态的应用程序的治理。然而，当初编写 Operator 并不容易，会面临一些挑战，如应用低级别 API、编写样板文件以及不足模块化性能（这会导致反复工作）。

Operator SDK 是一个框架，通过提供以下内容来升高 Operator 的编写难度：

  • 高级 API 和形象，用于更直观地编写操作逻辑
  • 支架和代码生成工具，用于疾速疏导新我的项目
  • 扩大项，笼罩常见的 Operator 用例

如上图所示，operator sdk能够基于helm、ansilbe和go构建operator，咱们需依据以后的状况抉择咱们适合的operator框架。

2.2 计划抉择

  • 计划一：golang 开发Operator

  • 计划二：ansible开发Operator

  • 计划三：golang和ansible混合开发Operator

依据Karmada的理论生产部署调研状况和vivo本身的实际，能够总结如下：

  1. 要反对在K8s集群和不依赖K8s集群二进制部署。
  2. 反对内部独立的etcd集群部署或者对接已有的etcd集群。
  3. Karmada集群具备迁徙能力，如机房裁撤和机器故障等，就须要etcd集群治理有备份和恢复能力，如依据etcd备份数据疾速在其它机房复原集群。
  4. 须要反对第三方的vip给Karmada-apiserver提供负载平衡，目前vivo都是基于内部vip，并提供了域名。没有应用K8s的service给Karmada-apiserver提供负载平衡。
  5. Karmada管制立体一键部署和member集群的自动化注册和登记。也须要获取member集群的kubeconfig，pull模式也须要在member集群部署Karmada-agent。
  6. Karmada集群的addons插件装置，如istio、anp、第三方的crd等装置，须要在Karmada的管制立体、host主机集群，甚至须要在member集群上进行配置。
  7. 提供api能力，实现可视化部署。
  8. 针对Karmada单个组件的独自降级和全量降级。
  9. 反对在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去执行。

首先咱们排除了计划一，对于计划二和计划三，自己也纠结了很长是工夫，最终咱们抉择了计划二。次要起因如下：

  1. Operator SDK ansible已具备了和Operator SDK go相等的能力，并提供K8s、K8s_status模块、类似的webhook性能去对k8s的资源管理，以及reconciliation的能力。
  2. 合乎目前Karmada理论生产部署的需要。
  3. 简略易学，只有晓得ansbile的jinja模版、和K8s雷同的yaml文件。你只须要编写ansible task，开箱即用，reconciliation由Operator SDK 解决。
  4. 对于罕用ansible的人比拟敌对，不须要写golang代码。
  5. 扩大能力强，用户可自定义插件。治理端也反对local、ssh、zeromq三种形式连贯。local模式能够间接对接K8s接口，ssh模式能够登录执行脚本。能够很好的混合应用，解决咱们以后的需要。
  6. 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集群的用户和密钥。

执行流程如下。

  1. 用户通过KarmadaDeployment定义Karmada操作
  2. Karmada Operator感知KarmadaDeployment的CR变动，开始进入控制器逻辑
  3. 依据用户的定义，抉择是容器化部署或者二进制部署，开始执行装置、扩所容和备份等操作
  4. 执行join/unjoin操作，将member集群注册到Karmada集群或者登记member集群

2.5 Karmada管制立体治理

如上图所示，次要是karmada管制立体生命周期治理，比照以后社区的部署工具咱们如下优化：

  1. 标准化证书治理，次要是用openssl生成证书。其中etcd和Karmada证书独自离开保护，和k8s集群证书命名雷同，不便接入咱们的监控。
  2. Karmada-apiserver反对内部负载平衡，不限于以后的k8s service提供的负载平衡。
  3. 更灵便的降级策略，反对独自组件降级和全量降级。
  4. 更丰盛的全局变量定义，打算反对组件配置变更等。

2.6 etcd集群治理

etcd集群是Karmada的元数据集群,生产中须要保障etcd集群高可用和故障复原等。如上图展现了etcd集群必要的生产因素，如主动扩缩容、降级、备份和etcd集群的故障复原。自研了基于ansible的plugins和library, 实现etcd集群治理能力如下：

  1. 增加member到存在的etcd集群。
  2. etcd集群删除member。
  3. etcd集群的备份，比方反对cephfs的数据备份。
  4. etcd集群故障复原。
  5. etcd集群衰弱状态查问。

这里定义了etcdBackup和etcdRestore的CR，没有合并到KarmadaDeployment里。次要思考到etcd集群自身操作的安全性和简化KarmadaDeployment的ansible工作。其中etcdRestore性能，能够依据etcd集群备份数据，实现导入到新的etcd集群，从而复原Karmada集群所有的业务状态。以后次要场景如下：

  1. Karmada集群所在的机房裁撤，须要备份etcd数据，迁徙到新的Karmada集群。
  2. 冀望通过Karmada-Operator治理Karmada集群，只需备份etcd数据，实现etcdRestore性能即可。
  3. Karmada集群故障，能够通过etcd备份数据，联合etcdRestroe实现故障复原。

2.7 member集群治理

member集群的生命周期治理次要有注册和登记，上图是执行的流程。为了解决member集群的注册和登记，这里会动静的生成inventory。Ansible Inventory 是蕴含动态 Inventory 和动静 Inventory 两局部的，动态 Inventory 指的是在文件中指定的主机和组，动静 Inventory 指通过内部脚本获取主机列表，并依照 ansible 所要求的格局返回给 ansilbe 命令的。

这里Karmada-Operator基于k8s的CR实现了动静inventory plugins，次要通过解析KarmadaDeployment的members定义去动静的生成inventory。这里增加了add-member和del-member 2个角色， add-member里集群会被注册到Karmada管制立体，del-member里的集群会被从Karmada管制立体登记，这样就能够并发的注册和登记多个member集群。同时也能够提供ssh登录模式，不便前期扩大。

三、Karmada-Operator的CI介绍

为了更好的进步开发人员的体验，打算提供Karmada-Operator的CI构建能力。这里在K8s集群里部署github的self-hosted Runner和kubevirt。

  1. 用户在github上提交PR
  2. 触发github Actions，咱们在self-hosted里定义的流程
  3. 执行语法和单元测试
  4. 通过kubevirt创立vm
  5. 在多个vm里部署1个host和2个member集群
  6. 部署Karmada和增加member集群
  7. 执行Karmada e2e和bookfinfo案例测试

打算增加的CI矩阵测试如下：

  • 语法测试：
  • ansible-lint
  • shellcheck
  • yamllint
  • syntax-check
  • pep8
  • 集群部署测试：
  • Karmadactl、charts、yaml和二进制部署和所有配置项装置测试
  • join/ unjoin member 集群
  • 降级Karmada
  • etcd集群的备份和复原
  • 功能测试：
  • Karmada e2e测试
  • 创立bookinfo案例
  • 性能测试：
咱们次要通过kubemark组件模仿了多个2000节点的member集群进行了性能测试，其中一个测试案例是集群故障转移，论断是4w个无状态pod可能在15分钟实现故障迁徙，有机会能够分享咱们的性能测试。

四、总结

通过社区的调研和vivo的实际，最终确定了Karmada-Operator方案设计。Karmada-Operator具备高度可扩展性、可靠性、更直观地编写操作逻辑和开箱即用等特点，咱们置信通过这种高度可扩大的申明式、自我修复云原生系统管理Karmada，为咱们全面切换到Karmada去治理业务提供了强有力牢靠保障。

基于ansible的operator也存在如下毛病。第一点没有提供webhook的能力，须要本人增加或者在ansible的task增加相干的校验；第二点是主动生成了通用的CRD模版，没有具体可定义的脚手架工具去主动生成CRD。

以后Karmada-operator还在初始阶段，提供了计划和局部实际，具体性能还需一直的欠缺和改良。具体能够查看vivo的Karmada-Operator仓库,欢送大家试用和提倡议。以后代码提供的能力矩阵能够查看我的项目布局。