K8s Operator

对K8S Operator的理解

我会尽量以通俗易懂的语言来阐述我个人对Operator的理解，我始终觉得用来验证你是否掌握一个新的东西，就在于你能否把这个东西给一个领域外的人讲，如果他可以明白个大概，那我觉得你对知识的理解就应该不会有太大问题。

预备知识:

1. 命令式API、声明式API
2. CRD(Custom Resource Definition)
3. 自定义Controller

生命式API

声明式，正如其名称所言，声明只关注结果，试想一下，如果你去饭馆吃饭，你只需要告诉服务员你想要吃酸辣土豆丝，剩下的统统不需要你操心，由厨子来负责(心疼厨子)。

对于计算机来说亦是如此，你只需要告诉计算机你想要的结果，剩余的过程交由计算机自己去摸索，你不必告诉它如何去达到这个目的，只需告诉它你最终想要的结果，至于怎么去完成取决去它自己。

命令时API

命令式则不然，它代表了你需要告诉计算机具体的执行步骤，第一步做什么，第二步做什么，第三步等等，如果你只告诉它第一步，而不告诉它后面的步骤，它就不知道干嘛了。

总结

命令式API:

​ 优点:简单、直接、逻辑完全体现在顺序、过程上

​ 缺点:当业务需求越来越复杂的时候，实际场景越来越复杂就不那么适用了

声明式API:

​ 优点:方便，快捷，只需要声明方定义资源，观察者进行观察，并执行即可。

​ 缺点:可能不是那么的通俗、直接。

例如在kubernetes中使用此两种方式来创建服务：

声明式

kubectl apply -f nginx.yaml ## 具体的需求是写在yaml文件中的，用户只需要执行这个yaml即可完成想要的结果

命令式

kubectl create deployment nginx --image nginx ## 你必须把你想完成的事情明明确确告诉它才行

CRD

CRD(Custom Resource Definition)的官方定义可以参考k8s官网，在这里我讲一下我个人对CRD的理解，我们可以从CRD本身出发

Resource （资源）可以理解为就是一个实例化的业务对象

Resource Definition（资源定义） 就是这个具体的业务对象都具有一些什么样的属性

Custom Resource Definition （自定义资源定义）就是可以由用户自己定义的具有一定属性的业务对象

所以通俗的讲,为什么会出现CRD，就是为了满足一些特定的用户需求，这些需求K8s本身并没有，所以允许用户进行自定义创建属于他们自己的业务，从而满足显示需求。

自定义Controller

Controller 即控制器，控制器自然是用于控制一些特定的东西的，这里特定的东西其实就是K8s里面的各种资源(Pod、Deployment...）

K8s Congtroller 会通过listen and watch机制不断去鉴定资源中的事件，并通过Reconcile 调谐函数作为响应，整个调整过程被称作 “Reconcile Loop”（调谐循环） 或者 “Sync Loop”（同步循环）。Reconcile 是一个使用资源对象的命名空间和资源对象名称来调用的函数，使得资源对象的实际状态与 资源清单中定义的状态保持一致。调用完成后，Reconcile 会将资源对象的状态更新为当前实际状态。我们可以用下面的一段伪代码来表示这个过程：

for {
  desired := getDesiredState()  // 期望的状态
  current := getCurrentState()  // 当前实际状态
  if current == desired {  // 如果状态一致则什么都不做
    // nothing to do
  } else {  // 如果状态不一致则调整编排，到一致为止
    // change current to desired status
  }
}

自定义的Controller和Controller没有什么区别，所谓自定义就是自己去定义一个满足你实际业务需求的Controller让它不断监控你的CRD，最终的目的就是使得期望状态和实际状态相吻合，这样我们的目的就达到啦！

实际的例子

还是最开始吃饭的例子，你点了一盘酸辣土豆丝以后，你突然又想点一个番茄炒蛋，然后你告诉厨子你又想要一份番茄炒蛋，厨子就会根据你的需求再去一份番茄炒蛋，如果后面你还想要别的菜，从原则上讲你可以一直告诉厨子，他会帮你完成，直到满足你的需求(这里只是举个生动形象的例子，现实中可不要这么干，不然会被厨子打的哈哈)

Operator

有了上面的铺垫知识，其实我们已经可以对Operator下定义了，对，其实Operator就是CRD+Controller

Operator=CRD+Controller

既然现在已经知道了什么是Operator，那么我们又应该如何创建自己的Operator,并把它部署到k8s集群里面呢，且听我细细道来。

CRD

1. 要想创建我们自己独有的CRD，我们先要使用K8s里面自带的CRD API，CRD API可以理解为所有API的元API，也就是通过这个API 是一个可以创建其他CRD API的元API。

2. 被创建出来的API，最终可以变为K8S里面可以被访问到的新的API，并且可以通过kubectl api-resources来进行查看

3. 至此我们就完成了CRD有关的操作。

Controller

前面说到自定义Controller作为CRD的一种行为，是要我们自行实现并部署到K8s里面中的，所以其实我们要做的事情也很明确，就是需要用代码去编写自定义CRD的逻辑，并以Pod的形式将这个自定义Controller部署到K8s里面，仅此而已。

那么问题来了，每个人的Controller和需求不同，难道每换一个需求，我们就要重新写一次我们的Controller代码，原则上说是这样的，但是还好前人已经考虑过这个问题了，所有有了Kubebuiler和Operatorsdk这两款开源项目,这两款工具实际都是帮我们最大化的减少了机械、重复的工作，让我们只关心我们业务的核心代码即可。