我们都知道可以使用k8s的Clientset来获取所有的原生资源对象，那么怎么能持续的获取集群的所有资源对象，或监听集群的资源对象数据的变化呢？这里不需要轮询去不断执行List操作，而是调用Watch接口，即可监听资源对象的变化，当资源对象发生变化，客户端即可通过Watch接口收到资源对象的变化。
Watch接口虽然可以直接使用，但一般情况下很少直接使用，因为往往由于集群中的资源较多，我们需要自己在客户端去维护一套缓存，而这个维护成本比较大。
也是因为如此，client-go提供了自己的实现机制，Informers应运而生。
什么是k8s informerinformers实现了持续获取集群的所有资源对象、监听集群的资源对象变化功能，并在本地维护了全量资源对象的内存缓存，以减少对apiserver、对etcd的请求压力。Informers在启动的时候会首先在客户端调用List接口来获取全量的对象集合，然后通过Watch接口来获取增量的对象，然后更新本地缓存。
此外informers也有很强的健壮性，当长期运行的watch连接中断时，informers会尝试拉起一个新的watch请求来恢复连接，在不丢失任何事件的情况下恢复事件流。另外，informers还可以配置一个重新同步的周期参数，每间隔该周期，informers就会重新List全量数据。
在informers的使用上，通常每个GroupVersionResource（GVR）只实例化一个informers，但有时候我们在一个应用中往往会在多个地方对同一种资源对象都有informer的需求，所以就有了共享informer，即SharedInformerFactory。所以可以通过使用SharedInformerFactory来实例化informers，这样本地内存缓存就只有一份，通知机制也只有一套，大大提高了效率，减少了资源浪费。
一图读懂k8s informer这里先给出一张k8s informer的详细架构图；
从图中可以看出，k8s informer主要包括以下几个部分：
1.Reflector（1）Reflector从kube-apiserver中list资源对象列表，然后调用DeltaFIFO的Replace方法将object包装成Sync/Deleted类型的Delta丢进DeltaFIFO中；
（2）Reflector从kube-apiserver中watch资源对象的变化，然后调用DeltaFIFO的Add/Update/Delete方法将object包装成Added/Updated/Deleted类型的Delta丢到DeltaFIFO中；
2.DeltaFIFODeltaFIFO中存储着一个map和一个queue；
（1）其中queue可以看成是一个先进先出队列，一个object进入DeltaFIFO中，会判断queue中是否已经存在该object key，不存在则添加到队尾；
（2）map即map[object key]Deltas，是object key和Deltas的映射，Deltas是Delta的切片类型，Delta中存储着DeltaType和object；另外，Deltas最末尾的两个Deleted类型的Delta会被去重；
DeltaType有4种，分别是Added、Updated、Deleted、Sync
Controller从DeltaFIFO的queue中pop一个object key出来，并从DeltaFIFO的map中获取其对应的 Deltas出来进行处理，遍历Deltas，根据object的变化类型更新Indexer本地缓存，并通知Processor相关对象有变化事件发生：
（1）如果DeltaType是Deleted，则调用Indexer的Delete方法，将Indexer本地缓存中的object删除，并构造deleteNotification struct，通知Processor做处理；
（2）如果DeltaType是Added/Updated/Sync，调用Indexer的Get方法从Indexer本地缓存中获取该对象，存在则调用Indexer的Update方法来更新Indexer缓存中的该对象，随后构造updateNotification struct，通知Processor做处理；如果Indexer中不存在该对象，则调用Indexer的Add方法将该对象存入本地缓存中，并构造addNotification struct，通知Processor做处理；
4.ProcessorProcessor根据Controller的通知，即根据对象的变化事件类型（addNotification、updateNotification、deleteNotification），调用相应的ResourceEventHandler（addFunc、updateFunc、deleteFunc）来处理对象的变化。
5.IndexerIndexer中有informer维护的指定资源对象的相对于etcd数据的一份本地内存缓存，可通过该缓存获取资源对象，以减少对apiserver、对etcd的请求压力。
informer所维护的缓存依赖于threadSafeMap结构体中的items属性，其本质上是一个用map构建的键值对，资源对象都存在items这个map中，key为资源对象的namespace/name组成，value为资源对象本身，这些构成了informer的本地缓存。
Indexer除了维护了一份本地内存缓存外，还有一个很重要的功能，便是索引功能了。索引的目的就是为了快速查找，比如我们需要查找某个node节点上的所有pod、查找某个命名空间下的所有pod等，利用到索引，可以实现快速查找。关于索引功能，则依赖于threadSafeMap结构体中的indexers与indices属性。
6.ResourceEventHandler用户根据自身处理逻辑需要，注册自定义的的ResourceEventHandler，当对象发生变化时，将触发调用对应类型的ResourceEventHandler来做处理。
k8s informer详细分析之前的文章也对k8s informer进行了一系列的详细分析，有兴趣的可以看一下对k8s informer的详细分析，这里给出k8s client-go/k8s informer分析系列的链接导航：
（1）informer概要分析；
（2）informer之初始化与启动分析；
（3）informer之Reflector分析；
（4）informer之DeltaFIFO分析；
（5）informer之Controller&Processor分析；
（6）informer之Indexer分析；