K8S controller介绍

k8s事件处理过程

简化后的k8s事件处理过程

详细的处理过程如下图所示。

image.png

上图中蓝色部分client-go已经帮我们实现，可以直接调用其中的方法；黄色部分是需要自己实现的内容。

Reflector

Reflector的作用是List&Watch我们资源的变化，每种类型资源都要实现一个List和一个Watch方法。
List： 拿到某类资源的所有列表。
Watch： 拿到资源的更新事件列表。
事件：

• ADDED
• MODIFIED
• DELETED
• BOOKMARKS： 更新客户端的ResourceVersion，以新的RV来Watch资源。

DeltaFIFO

DeltaFIFO是k8s中的一种存储类型，除此以外，k8s中还有以下几种存储类型（实现了Store Interface的ADD、DELETE、GET等接口。）。

• cache:实现Store，利用threadSafeMap存放数据。
• UndeltaStore:实现Store，利用cache存放数据，数据变更时通过PushFunc发送当前完整状态
• FIFO:实现Queue（包含Store），利用自己内部的items数据结构存放数据
• DeltaFIFO
• Heap:实现Store，利用data数据结构存放数据，实现堆数据结构，用于优先级队列
• ExpirationCache:实现Store，利用threadSafeMap存放数据

DeltaFIFO数据来源：

• Reflector的List
• Reflector的Watch: Reflector拿到不同的事件（ADDED、MODIFIED...），都会调用对应的方法（Added、Updated...）存储到DeltaFIFO中。
• Reflector的Resync

数据处理去向：

• 通过eventhandler将事件派发到workqueue
• 刷新本地缓存Indexer/Cache

DeltaFIFO处理完数据后，就会删除数据。cache会保存对应的数据，可以理解为cache中的数据和api-server中的数据一致。

Indexer/Cache

为了避免每一次获取资源信息都调用API到api-server中查询相应的数据，k8s会将数据保存在cache中，我们处理时如果是读取数据（如读取status、spec信息）就可以直接到cache中读取；如果是写入数据，如更新数据（如写入status信息），则调用API将数据写入到api-server中。

我们可以根据key（namespace/name）到cache中查询相应的信息。cache是informer的一部分，每种资源都有自己的informer，所以查询的时候，只需要提供key而不用指定是什么资源。

Informer

包含reflector、sharedprocessor、deltaFIFO、index/cache的集合，一般通过informer来操作资源。
每种资源都有自己的informer，informer需要添加eventHandler，包含onAdd、onDelete、onUpdate，添加对应的handler表示发生该事件时，需要调用对应的方法进行处理。推荐handler里的实现为把对应的事件加入到Workqueue，后面再由workqueue来处理。

• NewSharedIndexInformer 创建Informer的基本方法。
• NewDeploymentInformer 创建内建资源对象对应的Informer的方法，调用NewSharedIndexInformer实现
• NewSharedInformerFactory 工厂方法，内部有一个map存放我们创建过的Informer，达到共享informer的目的，避免重复创建informer对象，浪费内存

workerqueue

一般都是使用限速队列，因为限速队列包含了普通队列和延时队列的实现。

worker

worker只关心对象当前状态是否和预期的状态一致，若不一致则进行处理，所以即使是update，也只需要关心新的配置而不用关心旧的配置。