Kubernetes operator 模式开发实践

1.前言

近日我们在开发符合我们业务自身需求的微服务平台时，使用了 Kubernetes 的 Operator Pattern 来实现其中的运维系统，在本文，我们将实现过程中积累的主要知识点和技术细节做了一个整理。

读者在阅读完本文之后，会对 Operator Pattern 有一个基本的了解，并能将该模式应用到自己的业务中去。除此之外，我们也会分享要实现这一运维系统需要具备的一些相关知识。

注：阅读本文内容需要对 Kubernetes 和 Go 语言有基本了解。

2.什么是 Operator Pattern

在解释什么是 Operator Pattern 之前，我们得先了解在我们使用一个 Kubernetes 客户端——这里以 kubectl 举例——向 Kubernetes 集群发出指令，直到这项指令被 Kubernetes 集群执行结束，这段时间之内到底都发生了什么。

这里以我们输入 kubectl create -f ns-my-workspace.yaml 这条命令举例，这条命令的整条执行链路大致如下图所示：

ns-my-workspace.yaml

apiVersion: v1
kind: Namespace
metadata:
name: my-workspace

kubectl命令执行链路.png如上图所示，所有在 Kubernetes 集群中的组件交互都是通过 RESTful API 的形式完成的，包括第一步的控制器监听操作，以及第二步中 kubectl 发送的指令。虽说我们执行的是 kubectl create -f ns-my-workspace.yaml 指令，但其实 kubectl 会向「API服务器」发送一个 POST 请求：
curl --request POST
–url http://$k8s.host:${k8s.port}/api/v1/namespaces
–header ‘content-type: application/json’
–data ‘{
“apiVersion”:“v1”,
“kind”:“Namespace”,
“metadata”:{
“name”:“my-workspace”
}
}’

如上面的 cURL 指令，Kubernetes API 服务器接受的其实是 JSON 数据类型，而并非是 YAML。

然后所有这些创建的 resources 都会持久化到 etcd 组件中，「API服务器」也是 Kubernetes 集群中与「etcd」交互的唯一一个组件。

之后被创建的 my-workspace resource 就会被发送给监听了 namespaces resource 变更的 「Namespace控制器」中，最后就由「Namespace控制器」执行创建 my-workspace 命名空间的具体操作。那么同理，当创建 ReplicaSet resource 时就会由「ReplicaSet控制器」做具体执行，当创建 Pod 时，则会由「Pod控制器」具体执行，其他类型的 resource 与之类似，这些控制器共同组成了上图中的「Kubernetes API 控制器集合」。

说到这里，我们不难发现，实现 Kubernetes 中某一种领域类型——如上面提到的 Namespace、ReplicaSet、Pod，也即 Kubernetes 中的 Kind——的操作逻辑，需要具备两个因素：
1、对该领域类型的模型抽象，如上面的 ns-my-workspace.yaml 文件描述的 YAML 数据结构，这个抽象决定了 Kubernetes client 发送到 Kubernetes API server 的 RESTful API 请求，也描述了这个领域类型本身。
2、实际去处理这个领域类型抽象的控制器，如上面的「Namespace控制器」、「ReplicaSet控制器」、「Pod控制器」，这些控制器实现了这个抽象描述的具体业务逻辑，并通过 RESTful API 提供这些服务。

而当 Kubernetes 开发者需要扩展 Kubernetes 能力时，也可以遵循这种模式，即提供一份对想要扩展的能力的抽象，和实现了这个抽象具体逻辑的控制器。前者称作 CRD(Custom Resource Definition)，后者称作 Controller。

Operator pattern 就是通过这种方式实现 Kubernetes 扩展性的一种模式，Operator 模式认为可以将一个领域问题的解决方案想像成是一个「操作者」，这个操作者在用户和集群之间，通过一份份「订单」，去操作集群的API，来达到完成这个领域各种需求的目的。这里的订单就是 CR(Custom Resource，即 CRD 的一个实例)，而操作者就是控制器，是具体逻辑的实现者。之所以强调是 operator，而不是计算机领域里传统的 server 角色，则是因为 operator 本质上不创造和提供新的服务，他只是已有 Kubernetes API service 的组合。

而本文实践的「运维系统」，就是一个为了解决运维领域问题，而实现出来的 operator。

3. Operator Pattern 实战

在本节我们会通过使用 kubebuilder 工具，构建一个 Kubernetes Operator，在本节之后，我们会在自己的 Kubernetes 集群中获得一个 CRD 和其对应的 Kubernetes API 控制器，用于简单的部署一个微服务。即当我们 create 如下 YAML 时：
apiVersion: devops.my.domain/v1
kind: DemoMicroService
metadata:
name: demomicroservice-sample
spec:
image: stefanprodan/podinfo:0.0.1

可得到一个 Kubernetes 部署实例：

出现了deployment和pod.jpg
本节所有示例代码均提供在：
https://github.com/l4wei/kubebuilder-example

3.1 Kubebuilder 实现

Kubebuilder(https://github.com/kubernetes-sigs/kubebuilder)是一个用 Go 语言构建 Kubernetes APIs 控制器和 CRD 的脚手架工具，通过使用 kubebuilder，用户可以遵循一套简单的编程框架，使用 Go 语言方便的实现一个 operator。

3.1.1 安装
在安装 kubebuilder 之前，需要先安装 Go 语言和 kustomize，并确保可以正常使用。
kustomize 是一个可定制化生成 Kubernetes YAML Configuration 文件的工具，你可以通过遵循一套 kustomize 的配置，批量的生成你需要的 Kubernetes YAML 配置。kubebuilder 使用了 kustomize 去生成控制器所需的一些 YAML 配置。mac 用户可使用 brew 方便地安装 kustomize。

然后使用使用下面的脚本安装 kubebuilder：
os=$(goenvGOOS)arch=$(go env GOARCH)

download kubebuilder and extract it to tmp

curl -L https://go.kubebuilder.io/dl/2.2.0/$o$