利用 kubebuilder 优化 K8s Operator 开发体验

当前，Kubernetes 已经成为容器集群管理乃至云计算的事实标准。相比它曾经的竞争对手，如 Mesos、Docker Swarm 等，Kubernetes 最大的优势在于扩展性。而扩展性的一个重要体现，就是 Custom Resource 这一特性。

在这篇文章中，才云科技工程师 gaocegege 将围绕 kubebuilder，介绍如何利用 K8s 的扩展性简化 Operator 开发过程。

发布 | 才云 Caicloud

作者 | gaocegege

Kubernetes 本身有很多资源类型，例如最为人熟知的 Pod、Job、Deployment 等。通过 Custom Resource，用户可以定义自己的资源，并实现对应的 Operator（控制器）来处理对资源的请求。

用户实现的 Operator 通过与 Kubernetes 的 API server 交互，实现自身的业务逻辑。

什么是 kubebuilder

在没有 kubebuilder 之前，为了实现一个 Operator，用户需要完全实现从 Kubernetes Client 创建，到监听 Kubernetes API Server 请求，再到请求队列化，以及后面的业务逻辑等一整套逻辑。

在整个过程中，有一些逻辑是贯穿所有 Operator 实现过程的，因此 kubebuilder 将这些逻辑封装和抽象成了公共的库（controller-runtime）和公共的工具（controller-tools） 。

这之后，开发者在开发 Operator 时，就只需要通过 kubebuilder 生成一些 Scaffolding（脚手架）代码——他们不再需要关心 Kubernetes API Server 发来的请求是怎样进入请求队列、被依次执行的，只需要专注于如何处理当前的请求即可。至于其他事情，Scaffolding 代码中用到的 controller-runtime 等库会帮助处理。

在下文中，我将介绍利用 kubebuilder v1 scaffolding 简化 Operator 开发的具体做法。

开发流程

初始化项目 

首先，我们需要初始化项目：

初始化完成后，当前目录会生成一个最小可编译版本，但其中没有任何的 Operator 实现。目录结构如下所示：

其中，

• cmd 目录是关于可执行文件的代码；

• config 是在 Kubernetes 上部署 Operator 的配置文件；

• Dockerfile 是把 Operator 打包为 Docker 镜像的配置文件；

• Gopkg.toml 是自动生成的关于依赖的配置文件；

• hack 目录下是有关 Copyright Header 的文件；

• pkg 下是随后的 API 和代码实现。

创建 CRD 和 Operator 的 Scaffolding 代码 

之后，我们运行如下命令来创建 CRD 和对应的 Operator 实现：

可以看到，目录内生成了一些新的文件和目录：

其中，需要开发者修改的文件主要有两个： frigate_types.go  和  frigate_controller.go 。前者是 CRD 的 API 定义相关内容，后者是 CRD 对应的 Operator 实现。

修改 API 

在  frigate_types.go  中，我们可以看到有提示用户编辑的注释：

关于 Kubernetes Custom Resource API 定义相关内容，建议参考 Extend the Kubernetes API with CustomResourceDefinitions[1]，此处不再赘述。用户只需要修改对应的 Spec 与 Status 的数据结构。

值得一提的是，如果不依赖 kubebuilder 实现 Operator，通常开发者需要为定义好的 CRD 生成 Kubernetes Client、Informer 等，以便 Operator 利用其进行监听 API 请求等操作。

但 kubebuilder 使用的 controller-runtime 已经利用 dynamic client、unstructured client 和其他相关的方式完成了这些操作，因此无需生成 Kubernetes Client、Informer 等包。

修改 Controller 实现 

在 Controller 中，开发者需要做两处修改，一处为：

在这里，用户要指定 Operator 需要监听哪些资源的变动。

在这个示例中，Operator 监听了被定义的新资源拥有（Own）的 Deployment 的变动。当 Owner 为 Frigate 的 Deployment 的 Spec 或者 Status 一旦发生变动时，Operator 都会接收到来自 Kubernetes API Server 的请求。

另一处为  ReconcileFrigate  结构的方法  Reconcile ：

这里是处理所有来自 API Server 的请求的函数入口。

在这个例子中，每次请求都会根据 Custom Resource 的 name 在内存中维护一个期望的 Deployment 的实例，随后将其与 API Server 中已有的实例进行比对。

如果其 Spec 字段有不同之处，则通过 API Server 更新这一实例。Deployment Controller 会进行之后的处理，根据更新后的 Spec 修改在集群上的 Pod 的相关运行情况。

修编译与运行 Operator 

如果是在本地运行，我们需要利用  make manager  来编译 Operator 为二进制可执行文件。最后的可执行文件在 bin 目录下。 如果是运行在 Kubernetes 集群中，我们可以利用  make docker-push && make docker-push && make deploy  来进行部署。

Under the Hood

前方高能（难）！

上一节重点介绍了 kubebuilder 的使用方法，在这一节中，我们将“知其所以然”，看看 kubebuilder 生成的代码到底是怎么运行的。以下内容主要涉及 controller-runtime 中的实现， 因此要求读者具备一定的 Kubernetes 基础，以便更好地理解 。

首先我们来看看 cmd 中的代码：

之前说到，kubebuilder 是开发 Operator 的框架，但这个说法其实并不十分严谨。

准确来说，kubebuilder 是开发 Controller Manager 的框架 ，Controller Manager 会管理一个或者多个 Operator 。因此 cmd 中的代码也主要围绕 Controller Manager 展开： manager.New  首先创建了一个 Manager 实例，在这一实例中有 client、cache 等之后需要的对象。

apis.AddToScheme  将 CRD 的结构与 Kubernetes GroupVersionKinds 的映射添加到 Manager 的 Scheme 中。这一步是为了能够让 Manager 知道 CRD 的存在。

接下来，就是通过  controller.AddToManager  创建出定义的 Operator，并且添加到 Manager 中。 webhook.AddToManager  会创建对应的 Webhook，主要是做数据校验与默认值的赋值等操作，这里就不多介绍了，因为与 Controller 主要的逻辑无关 。

最后的  mgr.Start  会真正运行 Manager。 controller.AddToManager  中会利用  controller.New  创建出 Operator，然后 Watch 对应的资源，最后返回。

下面是  controller.New  的实现：

其中  options.Reconciler  就是我们定义的实现了  Reconcile  函数结构的实例。这一结构的  Reconcile  函数实现也就是前文中提到的 Operator 实现所需的第二处需要修改的地方。

mgr.SetFields(options.Reconciler)  利用依赖注入的方式，将 Manager 的 Client 和 Scheme 注入到  options.Reconciler  中，然后将其赋值给 Controller 中指向  reconcile.Reconciler  接口的字段 Do 中。

可以发现，除了这一字段，Controller 还有 Queue、Recorder、 Client 等其他字段。因此 kubebuilder 是对 Controller 进行了更高层次的抽象，其有关业务逻辑的实现都通过  reconcile.Reconciler  这一接口进行，而 Queue 等底层对象则由 kubebuilder 来替开发者维护。

最后， mgr.Add(c)  将 Operator 加入到 Manager 的一个 Operator 数组中。

接下来，我们回过头来看 Controller 是如何实现 Watch Kubernetes API Server 的资源的：

这里的 SetFields 是 Manager 将其自己的 SetFields 函数注入了进来，所以等同于调用了 Manager 的 SetFields 方法，其定义如下：

为了介绍具体实现，这里我们以  inject.CacheInto  为例，看看其检查被注入的对象有没有实现 Cache 接口，即有没有实现  InjectCache(cache cache.Cache) error  方法。

如果实现了，则执行注入，否则直接返回。也正是通过这样的方式，Manager 最终把 Cache 注入到了 Source 中，同时，如果需要的话，它也能把 Scheme 注入到 EventHandler  中。这里的 Scheme 在指定 Owner 的  EventHandler  会被用来获取 Owner 的  GroupKind 。

接下来，后面  src.Start(evthdler, c.Queue, prct...)  也就是顺理成章的实现了：

其利用被注入到 Source 中的 Cache 获取针对 Source 的资源类型的 Informer，然后将 EventHandler 作为处理 Informer 的事件的处理器。这就是 kubebuilder 的高层 API 背后做的事情。

写在最后

篇幅所限，关于 kubebuilder  的更多内容，大家可以阅读官方文档。 目前 kubebuilder 社区也已经推出了正在开发中的第二版实现，我会及时跟进，并在后续文章中为大家介绍新方法。

如果读者有新的想法和建议，欢迎留言指出，也欢迎大家 关注我们公司的公众号（ Caicloud2015 ），之后我们还会分享一系列内部技术和开源软件，敬请期待！

[1]https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/

完

感谢关注才云科技（公众号 ID：Caicloud2015），更多产品案例，欢迎访问 https://caicloud.io。

推荐阅读：

写留言

社区福利，戳 “阅读原文” ，CKA 上海场有机会立减 3288 元！