1.控制器的工作流程
当我们去API Server去获取任何对象的时候，我们可以有两种方式去获取，一种是get（主动），一种是watch（监听）
其中的lister就是把当前的状态返回给我，Informer就是说你有事件就通知我（消息通知机制）。
在Informer中有3种事件，增、删、改3种，AddEvent就是这个对象第一次出现的时候，从etcd删除就是delete event。
针对lister和informer，控制器怎么去配合这两个接口呢？这就需要注册这些事件EventHandler。大部分的控制器会拿到这个对象的keyFunc（keyFunc指的是这个对象的Namespace+name）,然后把这个对象的keyFunc放到队列里面去。接下来worker线程就会从对象里面去拿这个keyFunc，但是拿到的这个keyFunc不是完整的对象信息，所以worker会去lister里面去拿对象信息，lister会在本地缓存一份对象的信息，所以不会直接去API Server去拿对象信息。
那么为什么不是把一个对象放在队列里面，而是放置一个keyFunc呢？假设一个对象频繁变更，这样会导致队列的空间很快被沾满
1.1 Informer内部机制
首先Informer会跟API Server产生一个长连接，API Server这一端都是一个个的rest调用，它返回给客户端的是一个个的序列化好的字符串，这些字符串其实跟Go语言的这些K8S对象还没产生一一绑定关系，所以在Infomer这一段就会有一个Reflector通过反射机制来解析JsonTag，反射好后就会放入队列里面去。接下来Informer就会把这个完整的对象放到Indexer里面，在放的同时，也会触发一个事件，所以就需要对应事件的handler把key放到workQueue里面，然后worker拿到这些key就去indexer里面去拿具体的对象。
1.2 控制器的协同工作原理
Deployement描述的是一次部署行为（需要什么样的Pod，这个副本数是多少，其中副本集会用replicaSet来表示）
Deployment的template部分，表示的是Pod的模板，Deployment会为这个模板的内容做一个hash字符串，这个hash值将作为ReplicaSet名字的后端部分，所以，如果Pod模板里面的内容发生了变动，就意味着要做一次新的部署
2.通用Controller
Job是处理一次性业务的。
ServiceController一般是和LoadBalancer做配合的，用于配置外部的负载均衡器。
DaemonSetController是给集群管理员使用的，有时候集群管理员要部署一个应用，这个应用需要在集群里的每个节点跑一个Pod，比如说要收集日志，监控。DaemonSet Controller会watch当天集群内的所有节点，然后同时watch daemonSet这个对象，当daemonSet这个对象创建出来以后，就会为每一个节点创建一个对应的Pod，
3.Cloud Controller Manager
4.需要定制的Cloud Controller
5.来自生产的经验
6.确保scheduler和controller的高可用
