MySQL Operator 02 | 脚手架选型 & 工程创建
高日耀 资深数据库内核研发
毕业于华中科技大学，喜欢研究主流数据库架构和源码，并长期从事分布式数据库内核研发。曾参与分布式 MPP 数据库 CirroData 内核开发（东方国信），现主要负责 MySQL 系列产品内核开发（青云科技）。
本文是 MySQL Operator 设计第二篇，上一篇 介绍了 MySQL Operator 架构概览和设计思路。这一期将介绍 Operator 脚手架选型和工程创建过程。
| Operator 脚手架选型
建筑工地在建设房子的时候，最开始都要搭建一个脚手架，便于更快更安全的施工造房子。同样， Operator 工程的构建也要搭建一个脚手架，方便后续快速的开发和迭代，而 Kubernetes 社区有很多成熟的构建脚手架的工具供我们选择。
脚手架构建工具
Operator 框架 SDK：https://operatorframework.io/
Kubebuilder：https://book.kubebuilder.io/
KUDO（Kubernetes 通用声明式 Operator）：https://kudo.dev/
Charmed Operator 框架：https://juju.is/
目前社区活跃度和使用率最高的是 Operator SDK 和 Kubebuilder。它们都使用官方的 controller-tools 和 controller-runtime，有相同的布局，不同点在于：
Kubebuilder
包含 envtest 包，允许 Operator 开发人员使用独立的 etcd 和 apiserver 运行简单的测试
自动生成 Makefile 以帮助用户执行 Operator 任务（构建、测试、运行、代码生成等）
使用 kustomize 构建部署清单
改进了对准入和 CRD 转换 WebHooks 的支持
Operator SDK
更好的支持 Ansible 和 Helm operator 这类上层操作
与 Operator LifecycleManager(OLM) 的集成，OLM 是 Operator Framework 的一个关键组件，对于第 2 天集群操作非常重要，比如管理 Operator 实时升级
包含记分卡子命令，它可以帮助您理解 Operator 是否遵循最佳实践
包括 e2e 测试框架，它简化了对实际集群测试操作的过程
目前两个社区逐渐在融合，Operator SDK 也在不断向 Kubebuilder 靠拢，因此我们选择更原生、更嫡系的 Kubebuilder (目前到了 3.0 版本) 作为 Operator 工程的脚手架。
| 创建工程
初始化 Operator 和 Controller API
Kubebuilder 为 Operator 代码库中涉及的各种组件（如 CRD 和 Controller-API）的代码生成提供了快速教程和简单的脚手架，其架构如下所示：
创建步骤
按以下两个步骤创建工程：
1.初始化 Operator 工程
初始化域名设置为 radondb.com，将自动生成了镜像制作脚本，Makefile，配置文件以及 main.go 。指令如下：
2.创建 Controller
API、GVK(group, version, kind) 分别指定为 mysql, v1alpha1, MysqlCluster。
controller 参数设置为 true 意思是自动生成控制器初始的代码文件。指令如下：
通过两条指令生成的文件目录对比，执行第二条指令后，多了 api 目录，crd 目录以及 controllers 目录。
Project Layout 概览
以下为 radondb-mysql-kubernetes 项目的当前目录结构及功能介绍。
| 总结
Operator 基于 Kubernetes 的资源和控制器概念之上构建，同时又包含了应用程序特定的领域知识。创建 Operator 的关键是 CRD（自定义资源）的设计。下一篇我们将解析 radondb-mysql-kubernetes 项目中自定义 CRD 的设计。
相关阅读
版权声明: 本文为 InfoQ 作者【RadonDB开源社区】的原创文章。
原文链接:【http://xie.infoq.cn/article/a8cca3ed6a81923a88a14a0ef】。文章转载请联系作者。
https://radondb.com 2021.06.21 加入
一个面向云原生、容器化的数据库开源社区！
评论