Client对象
client-go支持4种客户端对象与Kubernetes API Server进行交互：
- RESTClient是最基础的客户端。RESTClient对 HTTP Request 进行了封装，实现了RESTful风格的API。
ClientSet、DynamicClient、DiscoveryClient客户端都是基于RESTClient实现的。 - ClientSet在 RESTClient 的基础上封装了对 Resource 和 Version 的管理方案。每一个 Resource 可以理解为一个客户端，而 ClientSet 则是多个客户端的集合，每一个 Resource 和 Version 都以函数的方式暴露给开发者。ClientSet只能够处理 Kubernetes 内置资源，它是通过 client-gen 代码生成器自动生成的（若需要访问CRD需要使用 client-gen 重新生成ClientSet）
- DynamicClient与 ClientSet 最大的不同之处是，ClientSet仅能访问 Kubernetes 自带的资源(即Client集合内的资源)，不能直接访问CRD自定义资源。DynamicClient能够处理 Kubernetes 中的所有资源对象，包括Kubernetes内置资源与CRD自定义资源。因为使用 Unstructured 结构，需要runtime.DefaultUnstructuredConverter.FromUnstructured 函数进行类型转化。
- DiscoveryClient为发现客户端，用于发现 kube-apiserver 所支持的资源组、资源版本、资源信息(即Group、Version、Resources)，将这些信息存储在本地，减轻 kube-apiserver 访问的压力，默认缓存存储在~/.kube/cache 和 ~/.kube/http-cache 下，缓存周期默认为10分钟。
以上4种客户端都可以通过 kubeconfig 配置信息连接到指定到Kubernetes API Server。
Informer机制
资源Informer
在Kubernetes系统中，组件之间通过HTTP协议进行通信，在不依赖任何中间件的情况下需要保证消息的实时性、可靠性、顺序性等，Kubernetes则通过使用cient-go的Informer机制达到这一效果。其他组件也是通过Informer机制与Kubernetes API Server进行通信的。
informer运行原理：
- Reflector：用于监控(Watch)指定的Kubernetes资源，当监控的资源发生变化时触发响应的变更事件（例如Added事件、Updated事件和Deleted事件），并将其资源对象存放到本地缓存DeltaFIFO中。
- DeltaFIFO：可以分开理解。FIFO是一个先进先出的队列，拥有队列操作的基本方法（Add，Update，Delete，List，Pop，Close等）；Delta是一个资源对象存储，可以保存资源对象的操作类型（Added、Updated、Deleted、Sync等）
- Indexer：是client-go用来存储资源对象并自带索引功能的本地存储，Reflector从DeltaFIFO中将消费出来的资源对象存储至Indexer。Indexer与Etcd集群中的数据完全一致。client-go可以很方便的从本地存储中读取相应的资源对象数据，无须每次从远程Etcd集群读取，减轻了api-server及Etcd集群的压力。
Shared Informer共享机制
Informer也被称为Shared Informer，它是可以共享使用的。若同一资源的Informer被实例化了多次，每个Informer使用一个Reflector，那么会运行过多的相同ListAndWatch ，太多重复的序列化和反序列化操作会导致api-server负载过重。
Shared Informer可以使同一个资源对象共享一个Reflector，这样可以节约很多资源；Shared Infor定义了一个map数据结构，通过map数据结构实现共享Informer机制。
内部机制：
WorkQueue
WorkQueue称为工作队列，Kubernetes的WorkQueue队列与普通的FIFO对比，实现略显复杂，它的主要功能在于标记和去重，并支持以下特性：
- 有序：按照添加顺序处理元素（item）
- 去重：相同元素在同一时间不会被重复处理，例如一个元素在处理前被添加了多次，它只会被处理一次。
- 并发性：多生产者和多消费者
- 标记机制：支持标记功能，标记一个元素是否被处理，也允许元素在处理时重新排队。
- 通知机制：ShutDown方法通过信号量通知队列不再接收新的元素，并通知metric goroutine退出。
- 延迟：支持延迟队列，延迟一段时间后再将元素存入队列。
- 限速：支持限速队列，元素存入队列时进行速率限制。限制一个元素被重新排队（Reenqueued）的次数。
- Metric：支持metric监控指标，可用于Prometheus监控。
WorkQueue支持3种队列，并提供3种接口，不同队列实现可应对不同的使用场景，分别如下：
- Interface：FIFO队列接口，先进先出队列，并支持去重机制。
- DelayingInterface：延迟队列接口，基于 Interface 接口封装，延迟一段时间后再将元素存入队列。
- RateLimitingInterface：限速队列接口，基于 DelayingInterface 接口封装，支持元素存入队列时进行速率限制，限速算法有令牌桶算法、排队指数算法、计数器算法和混合模式。
EventBroadcaster事件管理器
Kubernetes的事件（Event）是一种资源对象（Resource Object），用于展示集群内发生的情况，Kubernetes系统中的各个组件会将运行时发生的各种事件上报给Kubernetes API Server。由于Kubernetes的事件是一种资源对象，因此它们存储在Kubernetes API Server的Etcd集群中。为避免磁盘空间被填满，故强制执行保留策略：在最后一次的事件发生后，删除1小时之前发生的事件。
- EventRecorder：事件（Event）生产者，也称为事件记录器Kubernetes系统组件通过EventRecorder记录关键性事件。
- EventBroadcaster：事件（Event）消费者，也称为事件广播器。EventBroadcaster消费EventRecorder记录的事件并将其分发给目前所有已连接的broadcasterWatcher。分发过程有两种机制，分别是非阻塞（Non-Blocking）分发机制和阻塞（Blocking）分发机制。
- BroadcasterWatcher：观察者（Watcher）管理，用于定义事件的处理方式，例如上报事件至Kubernetes API Server，最终存储在Etcd集群中。
