kubebuilder的由来

在我们使用基于k8s的云平台部署和运维自己的应用时，拿openshift举例，如果我们想管理一个基于Rails的web应用，我们需要调用k8的api服务分别为web和数据库定义很多资源(bc, dc, svc, pvc, route, pod, service, configmap, secrets)等。这些资源通过k8s的controller-manager, scheduler等控制器和巡检器协同工作，保证这些资源和相对应的服务处于一种我们希望的状态。尽管有通用template等可以将这些资源进行整合，但无疑存在重复的操作和冗余管理。

k8支持用户对资源类型和控制器进行扩展和自定义。这个自定义的资源和控制器就是operator。支持了operator，我们根据自己的需要定义自己的operator，就不再使用通用的dc, bc这些资源而定义自己的资源和如何控制及其操作。由通用资源和通用控制器到自定义资源和自定义控制器，简化了基于k8云平台的自动化部署和运维。然而，自定义operator还是有很多重复工作，为了减少这些重复工作和规范operator，就有了kubebuilder，其为构建Kubernetes控制器（operator）的提供了框架和工具集。

回到最初的那个例子：现在如果我们在openshift或其他k8云平台部署自己的应用，我门就可以使用kubebuilder快速构建一个数据库的operator(自定义数据库资源和控制器)，和一个web的operator即可。

我是2017年年底就开始使用openshift部署应用了，在2019年团队就开始使用operator，2022年团队已经开始了kubebuilder最佳实践的分享，我因为个人项目原因从2019年就减少了operator相关新技术的使用和学习。我们团队的使用，通常会落户于k8社区2年左右，我个人落后了许多。

现在和大家一起学习进步，追上大部队。