关于容器:多云容器编排-KarmadaOperator-实践

作者：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 仓库, 欢送大家试用和提倡议。以后代码提供的能力矩阵能够查看我的项目布局。