使用CRD创建出自定义API对象后，就是为这个 API 对象编写一个自定义控制器（Custom Controller），这样， Kubernetes 才能根据 自定义 API 对象的“增、删、改”操作，在真实环境中做出相应的响应。
编写自定义控制器分为三个过程：编写 main 函数、编写自定义控制器的定义，以编写控制器里的业务逻辑。
自定义控制器工作流程
首先从 Kubernetes 的 APIServer 里获取它所关心的对象，也就是自定义的控制器对象。这个操作，依靠的是一个叫作 Informer（通知器）的代码库完成的；Informer 与 API 对象是一一对应的，所以需要传递给自定义控制器一个Informer；
Informer是一个带有本地缓存和索引机制的、可以注册EventHandler 的 client。它是自定义控制器跟 APIServer 进行数据同步的重要组件。
创建Informer的时候需要传一个Client，Informer 正是使用Client，跟 APIServer 建立了连接；真正负责维护这个连接的是 Informer 所使用的 Reflector 包。
Reflector 使用的是一种叫作ListAndWatch的方法，来“获取”并“监听”这些API对象实例的变化（Informer通过 ListAndWatch，把 APIServer 中的 API 对象缓存在了本地，并负责更新和维护这个缓存。）在 ListAndWatch 机制下，一旦 APIServer 端有新的API对象实例被创建、删除或者更新， Reflector 都会收到“事件通知”；这时，该事件及它对应的 API 对象这个组合，就被称为增量 （Delta），它会被放进一个 Delta FIFO Queue（即：增量先进先出队列）中；Informe 会不断地从 Delta FIFO Queue 里读取（Pop）增量。每拿到一个增量，Informer 就会判断这个增量里的事件类型，然后创建或者更新本地对象的缓存；这个缓存，在 Kubernetes 里一般被叫作 Store
Informer 的第二个职责，则是根据这些事件的类型，触发事先注册好的 ResourceEventHandler；
这些 Handler，需要在创建控制器的时候注册给它对应的 Informer。
Informer 与要编写的控制循环之间，则使用了一个工作队列来进行协同，防止控制循环执行过慢把Informer拖死。
接下来就是熟悉的控制循环的逻辑了
参考链接：
https://www.zhihu.com/question/22285830/answer/469177185
https://www.pianshen.com/article/40791568713/