controller的用途

ReplicaSet、Deployment、StatefulSet：用于无状态和有状态应用的副本管理。

DaemonSet：确保每个节点上都运行一个副本的控制器。

Job 和 CronJob：用于处理批量任务和定期任务。

HorizontalPodAutoscaler (HPA)：用于自动扩缩容 Pods。

Ingress Controller：负责流量的路由与负载均衡。

NetworkPolicy：用于定义网络访问控制策略。

实现机制

K8s HTTP API 的 List Watch 机制

Controller 需要监控 K8s 中资源的状态，这是如何实现的呢？

K8s API Server 提供了获取某类资源集合的 HTTP API，此类 API 被称为 List 接口。例如下面的 URL 可以列出 default namespace 下面的 pod。

HTTP GET api/v1/namespaces/default/pods

在该 URL 后面加上参数 ?watch=true，则 API Server 会对 default namespace 下面的 pod 的状态进行持续监控，并在 pod 状态发生变化时通过 chunked Response (HTTP 1.1) 或者 Server Push（HTTP2）通知到客户端。K8s 称此机制为 watch。

Informer 机制

采用 k8s HTTP API 可以查询 K8s API 资源对象并 Watch 其变化，但大量的 HTTP 调用会对 API Server 造成较大的负荷，而且网络调用可能存在较大的延迟。除此之外，开发者还需要在程序中处理资源的缓存，HTTP 链接出问题后的重连等。为了解决这些问题并简化 Controller 的开发工作，K8s 在 client go 中提供了一个 informer 客户端库。

在 Kubernetes 中，Informer 是一个客户端库，用于监视 Kubernetes API 服务器中的资源并将它们的当前状态缓存到本地。Informer 提供了一种方法，让客户端应用程序可以高效地监视资源的更改，而无需不断地向 API 服务器发出请求。

采用 Informer 机制编写的 Controller 中的主要流程如下：

1. Reflector 采用 K8s HTTP API List/Watch API Server 中指定的资源。 Reflector 会先 List 资源，然后使用 List 接口返回的 resourceVersion 来 watch 后续的资源变化。对应的源码：Reflector ListAndWatch。
2. Reflector 将 List 得到的资源列表和后续的资源变化放到一个 FIFO（先进先出）队列中。 对应的源码：使用 List 的结果刷新 FIFO 队列将 Watch 收到的事件加入到 FIFO 队列
3. Informer 在一个循环中从 FIFO 队列中拿出资源对象进行处理。对应源码：processLoop。
4. Informer 将从 FIFO 队列中拿出的资源对象放到 Indexer 中。对应的源码：processDeltas。 Indexer 是 Informer 中的一个本地缓存，该缓存提供了索引功能（这是该组件取名为 Indexer 的原因），允许基于特定条件（如标签、注释或字段选择器）快速有效地查找资源。此处代码中的 clientState 就是 Indexer，来自于NewIndexerInformer方法中构建的 Indexer，该 Indexer 作为 clientState 参数传递给了 newInformer 方法。
5. Indexer 将收到的资源对象放入其内部的缓存 ThreadSafeStore 中。
6. 回调 Controller 的 ResourceEventHandler，将资源对象变化通知到应用逻辑。对应的源码：processDeltas。
7. 在 ResourceEventHandler 对资源对象的变化进行处理。