K8S controller介绍

发表于 更新于 分类于 阅读次数：

k8s事件处理过程

简化后的k8s事件处理过程
k8s的事件处理过程如上图所示。大致可以分为Informer、EventHandler、Workqueue、Worker四块。
每种类型的资源都有各自的Informer（与GVK对应？），例如Pod有自己的Pod Informer。当我们创建Pod时，Pod Informer里的Reflector会List&Watch到Pod的创建，将其加入到DeltaFIFO queue中。然后调用Informer里注册的EventHandler中的对应的事件处理函数，将Pod的key（namespace/name）加入到Workqueue中，同时DeltaFIFO也会将Pod的信息保存到Indexer中。最后，Worker到Workqueue中Get到key，并根据key到Indexer中拿到Pod的相关信息，并处理Pod的创建。

详细的处理过程如下图所示。
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，也只需要关心新的配置而不用关心旧的配置。

每一种 API 资源对象都会有对应的 Informer,

1
2
3
4
type DeploymentInformer interface {
    Informer() cache.SharedIndexInformer
    Lister() v1.DeploymentLister
}
  • Informer：
    • 同步本地缓存，把 API 资源对象缓存一份到本地
    • 根据发生的事件类型，触发事先注册好的控制器回调
  • Lister：
    • 从本地缓存中获取 API 资源对象

informers.SharedInformerFactory和cache.SharedIndexInformer的区别:

  • 前者是实时从api-server拿到API资源状态，后者是缓存起来的API资源状态,可以通过GetStore()或GetIndexer()获取，定期更新，workqueue就是从此处获取资源状态，资源Informer（informers.SharedInformerFactory）里的Informer方法把资源状态存入cache.SharedIndexInformer，Lister方法从cache.SharedIndexInformer读取资源状态。

informer分为2类，一类为原生的，一类为crd的。原生的Informer是一个大集合informers.SharedInformerFactory，包含所有gvk的informer,需要具体资源的informer只需要定义一个具体资源的，但Start函数用SharedInformerFactory的。

  1. 一般用不到watch，watch的时候不能带selector。
  2. 要watch事件，建议用informer；实时性要求不高的，轮询event即可。
  3. Pod状态知识
    3.1: Phase=Running, Condition.Type=ContainersReady，表示所有容器ready
    3.2: Phase=Running, Condition.Type=Initialized，表示所有init容器启动成功
    3.2: Phase=Running, Condition.Type=Ready，表示Pod已经可以提供服务
    3.2: Phase=Running, Condition.Type=PodScheduled,表示Pod在调度中，具体调度结果看Condition.Status
    3.5: 镜像不存在/拉不下来，Pod状态为Pending。
  4. 跳出for-select循环： 1. goto, 2. return 3. break 标签