初始化相关知识点
创建operator的第一步，就是用kubebuilder命令行创建整个项目，这个在《kubebuilder - 创建项目》已经试过，当时执行的是如下三行命令：

mkdir -p $GOPATH/src/helloworld
cd $GOPATH/src/helloworld
kubebuilder init --domain com.bolingcavalry

在用上module之后，大家已经脱离了GOPATH/src下面操作就略有些别扭了，来试试不用$GOPATH的初始化方式；

• 随处新建一个目录(路径中不要有中文和空格)，例如~/temp/202102/15/elasticweb

• 在目录中用go mod init elasticweb命令新建名为elasticweb的工程；

• 再执行kubebuilder init --domain com.bolingcavalry，即可新建operator工程；

基础设施

• operator工程新建完成后，会新增不少文件和目录，以下几个是官方提到的基础设施：
• go.mod：module的配置文件，里面已经填充了几个重要依赖；
• Makefile：非常重要的工具，前文咱们也用过了，编译构建、部署、运行都会用到；
• PROJECT：kubebuilder工程的元数据，在生成各种API的时候会用到这里面的信息；
• config/default：基于kustomize制作的配置文件，为controller提供标准配置，也可以按需要去修改调整；
• config/manager：一些和manager有关的细节配置，例如镜像的资源限制；
• config/rbac：顾名思义，如果像限制operator在kubernetes中的操作权限，就要通过rbac来做精细的权限配置了，这里面就是权限配置的细节；

main.go

main.go是kubebuilder自动生成的代码，这是operator的启动代码，里面有几处值得注意：

1. 两个全局变量，如下所示，setupLog用于输出日志无需多说，scheme也是常用的工具，它提供了Kind和Go代码中的数据结构的映射，：

var (
    scheme   = runtime.NewScheme()
    setupLog = ctrl.Log.WithName("setup")
)

2. 另外还有些设置，例如监控指标相关的，以及管理controller和webhook的manager，它会一直运行下去直到被外部终止，关于这个manage还有一处要注意的地方，就是它的参数，下图是默认的参数，如果您想让operator在指定namespace范围内生效，还可以在下午的地方新增Namespace参数，如果要指定多个nanespace，就使用cache.MultiNamespacedCacheBuilder(namespaces)参数：

image.png

3. main.go的内容在大多数场景无需改动，了解即可，接下来的API是重头戏；

API相关（数据核心）

• API是operator的核心，当您决定使用operator时，就应该从真实需求出发，开始设计整个CRD，而这些设计最终体现在CRD的数据结构，以及对真实值和期望值的处理逻辑中；
  -《 kubebuilder - 创建项目》kubebuilder创建过API，当时的命令是：

kubebuilder create api \
--group webapp \
--version v1 \
--kind Guestbook

• kubebuilder自动新增了很多内容，如下图，都是为了这个CRD服务的：

  
  image.png

新增的内容中，最核心的当然是CRD了，也就是上图中Guestbook数据结构所在的guestbook_types.go文件，这个最重要的数据结构如下：

type Guestbook struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`

    Spec   GuestbookSpec   `json:"spec,omitempty"`
    Status GuestbookStatus `json:"status,omitempty"`
}

1. metav1.TypeMeta：保存了资源的Group、Version、Kind
2. metav1.ObjectMeta：保存了资源对象的名称和namespace
3. Spec：期望状态，例如deployment在创建时指定了pod有三个副本
4. Status：真实状态，例如deployment在创建后只有一个副本(其他的还没有创建成功)，大多数资源对象都有此字段，不过ConfigMap是个例外（想想也是，配置信息嘛，配成啥就是啥，没有什么期望值和真实值的说法）；
5. 还有一个数据结构，就是Guestbook对应的列表GuestbookList，就是单个资源对象的集合；
   guestbook_types.go所在目录下还有两个文件：groupversion_info.go定义了Group和Version，以及注册到scheme时用到的实例SchemeBuilder，zz_generated.deepcopy.go用于实现实例的深拷贝，它们都无需修改，了解即可；

controller相关（业务核心）

前面聊过了数据核心，接下来要讨论如何实现业务需求了，在operator开发过程中，尽管业务逻辑各不相同，但有两个共性：

1. Status(真实状态)是个数据结构，其字段是业务定义的，其字段值也是业务代码执行自定义的逻辑算出来的；
   2 业务核心的目标，是确保Status与Spec达成一致，例如deployment指定了pod的副本数为3，如果真实的pod没有三个，deployment的controller代码就去创建pod，如果真实的pod超过了三个，deployment的controller代码就去删除pod;

以上就是咱们的controller要做的事情，接下来看看代码的细节，kubebuilder创建的guestbook_controller.go就是controller，咱们的业务代码都写在这个文件中，来看看kubebuilder准备了什么：

3. 数据结构定义，如下所示，操作资源对象时用到的客户端工具client.Client、日志工具、Kind和数据结构的关系Scheme：

type GuestbookReconciler struct {
    client.Client
    Log    logr.Logger
    Scheme *runtime.Scheme

4. SetupWithManager方法，在main.go中有调用，指定了Guestbook这个资源的变化会被manager监控，从而触发Reconcile方法：

func (r *GuestbookReconciler) SetupWithManager(mgr ctrl.Manager) error {
    return ctrl.NewControllerManagedBy(mgr).
        For(&webappv1.Guestbook{}).
        Complete(r)

5. 如下图，Reconcile方法前面有一些+kubebuilder:rbac前缀的注释，这些是用来确保controller在运行时有对应的资源操作权限，例如红框中就是我自己添加的，这样controller就有权查询pod资源对象了：

   
   image.png

• guestbook_controller.go是operator的业务核心，而controller的核心是其Reconcile方法，将来咱们的大部分代码都是写在这里面的，主要做的事情就是获取status，然后让status和spec达成一致；

• 关于status，官方的一段描述值得重视，如下图红框，主要是说资源对象的状态应该是每次重新计算出来的，这里以deployment为例，想知道当前有多少个pod，有两种方法，第一种准备个字段记录，每次对pod的增加和删除都修改这个字段，于是读这个字段就知道pod数量了，第二种方法是每次用client工具去实时查询pod数量，目前官方明确推荐使用第二种方法：

  
  image.png

至此，基础知识串讲就完成了