Kubernetes Informer 机制

除了CRI之外,大多数 Kubernetes 组件都遵循 声明式接口 来设计

CRI 采用命令式接口的原因主要有以下两点

  1. 所有的运行时都需要重新实现相同的逻辑支持很多 Pod 级别的功能和机制;
  2. Pod 的定义在 CRI 设计时演进地非常快,初始化容器等功能都需要运行时的配合;

虽然社区最终为 CRI 选择了命令式的接口,但是 Kubelet 仍然会保证 Pod 的状态会不断地向期望状态迁移。

Apiserver 在接收请求之后,会在ETCD中保存当前pod的相关状态,然后其他组件会来对状态进行查询,进行状态迁移,可以参考 Kubernetes Pod 创建过程,这种机制会导致 Apiserver的负载过大而且效率低下

Informer 主要用来充当 Apiserver 和 控制器 之间的中间层,基于事件机制,一方面构建本地缓存,一方面触发事件方法,使得控制器能够快速响应和快速获取数据,主要使用的是 List&Watch机制

控制器 并不是 通过不断轮询api,不停地调用List和Get,获取到对象的期望状态

而是使用Informer 依赖Etcd的Watch机制,通过事件来获知对象变化状态,建立本地缓存

Etcd的watch机制是一种类 订阅模式 的机制,监听一个或一组key,key的任何变化都会发出消息

List&Watch只会执行一次,即先执行List把数据拉过来,放入队列中,后续就进入Watch阶段。为了让不同的apiserver能够均匀负载这些Watch请求,客户端会主动断开跟apiserver的连接,这个超时时间为60秒,然后重新发起Watch请求

Send a Message