内容：

最近疫情期间不能入职，就先在家提前学习入职的内容，导师安排了了解K8s，记录一下看到的K8s的一种消息
机制：List-Watch机制。

在通信时，要保证消息实时性经常采用轮询，可能导致问题出现：

1、客户端轮询服务端：那么服务端压力会很大2、服务端主动建立连接发消息告知，此时若http消息则不安全，而且还有大量端口占用问题

K8s的List-Watch机制：

1、依赖于K8s组件中的Etcd分布式数据库存储集群信息，任何操作都是通过apiserver来修改Etcd的，其它组件不可以直接与Etcd通信客户端(kubelet/scheduler/controller-manager)通过list-watch监听apiserver中资(pod/rs/rc等等)的create,update和delete事件，并针对事件类型调用相应的事件处理函数。2、list-watch有两部分组成，分别是list和watch。list：调用资源的list API罗列资源，基于HTTP短链接实现；watch：调用资源的watch API监听资源变更事件，基于HTTP 长链接实现；K8S的informer模块封装list-watch API，用户只需要指定资源，编写事件处理函数，AddFunc,UpdateFunc和DeleteFunc等。informer首先通过list API罗列资源，然后调用watch API监听资源的变更事件，并将结果放入到一个FIFO 队列，队列的另一头有协程从中取出事件，并调用对应的注册函数处理事件。注意：Informer还维护了一个只读的Map Store缓存，提升查询的效率，降低apiserver负载。

List-Watch消息通知机制：

四个要素：消息可靠性消息实时性消息顺序性高性能1、可靠性：
list和watch一起保证了消息的可靠性，避免因消息丢失而造成状态不一致场景。list API可以查询当前
的资源及其对应的状态(即期望的状态)，客户端通过拿期望的状态和实际的状态进行对比，纠正状态不一致
的资源。Watch API和apiserver保持一个长链接，接收资源的状态变更事件并做相应处理。如果仅调用
watch API，若某个时间点连接中断，就有可能导致消息丢失，所以需要通过list API解决消息丢失问题。
我们可以认为list API获取全量数据，watch API获取增量数据。虽然仅仅通过轮询list API，也能达到
同步资源状态的效果，存在上面提到轮询的缺点：开销大，实时性不足的问题。
（也就是说list机制用于辅助修正）2、实时性：
list-watch机制下，每当apiserver的资源产生状态变更事件，都会将事件及时的推送给客户端，从而保证
消息的实时性。3、顺序性：
在并发的场景下，客户端在短时间内可能会收到同一个资源的多个事件，对关注最终一致性的K8S来说，它需
要知道哪个是最近发生的事件，并保证资源的最终状态如同最近事件所表述的状态一样。K8S在每个资源事件
中都带一个resourceVersion的标签，这个标签是递增的数字，所以当客户端并发处理同一个资源事件时，
它就可以对比resourceVersion来保证最终的状态和最新的事件所期望的状态保持一致。
（客户端就通过resrouceVersion来确定数据是不是处于同一时间版本）4、高性能：
List-watch通过异步通知达到高性能的特点，因为虽然仅通过周期性调用list API也能达到资源最终一致
性的效果，但是周期性频繁的轮询大大的增大了开销，增加apiserver的压力。而watch作为异步消息通知
机制，复用一条长链接，保证实时性的同时也保证了性能。

大四学生一枚，如果文章有错误的地方，欢迎在下方提出，每条评论我都会去认真看并回复，同时感谢指正的前辈。有喜欢C/C++，linux的同学欢迎私信一起讨论学习。