k8s informer内部机制与控制器工作原理

k8s informer内部机制与控制器工作原理

@[toc]

informer内部机制

注意点：任何控制器都应该用shareinformer，所有的对象只要在客户端(控制器)，所有对象在本地已有缓存，由shareinformer来保证本地缓存和apiserver一致性，例如二开控制器时，尽量减少对apiserver的操作，如果更新操作可以通过apiserver来刷新数据，Thread Safe store为本地内存里边的。

控制器原理

可以理解为生产者与消费者模型，任何的k8s对象都会生成informer(观察框架)和lister(获取全量数据的框架)，当我们去生成控制器时，例如基于Kubebuild，或者社区的cilmconpler仿写控制器，第一步就是通过lister和informer去观察监听某一个对象，监听的对象就会有一些event(如Add、Delete、Update)，不同的event可以注册handler，发生event把对象的key（namespace和name）取出来放到Ratelimitq里面，另外一边会启gorouting，可以配置多个worker，不停的从queue里边获取数据，只要队列里边有数据，说明对象变化还未被处理，worker主要工作就是完成配置，直到队列里空为止，如果出错，就会以ratelimit方式enqueue回去。

控制器协同工作原理

创建了dp资源对象之后，发给apiserver组件,apiserver会进行认证鉴权(读取本地配置文件)，之后会存储到etcd数据库中，接下来就是集群的大脑controller manager组件开始干活了，具体也可通过查看日志kubectl logs -f kube-controller-manager-x.x.x.x -nkube-system，它的行为主要依赖deployment里的yaml定义（例如：需要5个副本，运行nginx镜像），然后会创建一个replicasets对象，包括pod的模板，副本数，创建RS之后会发到apiserver，controller manager里边也有一个ReplicaSet Controller，它也在监听apiserver，发现有一个rs的创建请求，发现pod不存在，就新建一个Pod，创建完之后查看pod详细信息有一个nodeName属性，这时调度器来做调度，它背后的逻辑一直是watch资源的对象（例如目前介绍的Pod），它首先会过滤当前集群不符合调度pod资源的节点，其次在符合要求的节点里选择打分比较高的节点，整个调度结束之后会把结果返回给apiserver；接下来由节点上的kubelet组件干活，首先会看apiserver中的pod信息，对比本地是否存在该容器pod，不存在的话说明是一个新pod，然后执行创建pod的动作：k8s启动docker不会挂载网络，使用cni插件，只启runtime，例如pod需挂载存储，k8s也有对应的csi插件来实现。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。