Kubernetes&&工作原理

Kubernetes List-Watch机制原理

List-Watch 是 Kubernetes 统一的异步消息处理机制，各组件间协同都采用该机制进行通信，对系统的性能、数据一致性起到关键性的作用。

List-Watch 的组成

• list 调用资源的list API罗列资源，获取静态的所有数据，主要用于查询，基于HTTP短链接实现。
• watch 调用资源的watch API,监听每个资源的增删改事件，基于HTTP长链接实现。

client端在跟server端长期进行交互时，并不是每次需要查询时都去调用server的接口，而是使用list + watch的方式来维护一个缓存将server端的数据缓存起来，当需要获取数据的时候直接从缓存中获取，一方面可以降低server端的压力，另一方面也可以减少自己获取数据的时间。当然，增删改还是需要调用server端的接口。

异步消息处理机制的特点

• 消息可靠性: 首先消息必须是可靠的，list 和 watch 一起保证了消息的可靠性，避免因消息丢失而造成状态不一致场景。具体而言，List API可以查询当前的资源及其对应的状态（即期望的状态），客户端通过期望的状态和实际的状态进行对比，纠正状态不一致的资源。Watch API 和 apiserver 保持一个长链接，接收资源的状态变更事件并做相应处理。
• 消息实时性: List-Watch机制下，每当apiserver的资源产生状态变更事件，都会将事件及时的推送给客户端，从而保证了消息的实时性。
• 消息顺序性: 在并发的场景下，客户端在短时间内可能会收到同一个资源的多个事件，为保证资源的最终状态，K8S在每个资源的事件中都带一个resourceVersion的标签，这个标签是递增的数字，所以当客户端并发处理同一个资源的事件时，它就可以对比此标签来保证最终的状态和最新的事件所期望的状态的一致。
• 高性能: 虽然仅通过周期性调用list API也能达到资源最终一致性的效果，但是周期性频繁的轮询大大的增大了开销，增加apiserver的压力，而watch作为异步消息通知机制，复用一条长链接，保证实时性的同时也保证了性能。

watch是如何实现的

watch 实现的核心是Chunked transfer encoding（分块传输编码）。

HTTP 分块传输编码允许服务器为动态生成的内容维持HTTP持久链接。通常，持久链接需要服务器在开始发送消息体前发送 Content-Length 消息头字段（表示数据的长度），但是对于动态生成的内容来说，在内容创建完之前是不可知的。使用分块传输编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。

• 如果一个HTTP消息（包括客户端发送的请求消息或服务器返回的应答消息）的Transfer-Encoding 消息头的值为chunked，那么，消息体由数量未定的块组成，并以最后一个大小为0的块为结束。
• 每一个非空的块都以该块包含数据的字节数（字节数以十六进制表示）开始，跟随一个CRLF（回车及换行），然后是数据本身，最后块CRLF结束。在一些实现中，块大小和CRLF之间填充有白空格（0x20）。
• 最后一块是单行，由块大小（0），一些可选的填充白空格，以及CRLF。最后一块不再包含任何数据，但是可以发送可选的尾部，包括消息头字段。
• 消息最后以CRLF结尾。

通过curl命令 watch pods 资源

Scheduler：为 Pod 找到一个合适的 Node

先执行Predicates函数，后执行Priority函数。

Predicate，预选函数

• CheckNodeCondition: 检查Node是否符合调度条件。
• HostName: 检查 Node 的名字是否为 Pod 的指定的 Hostname。
• MatchNodeSelector: 检查 Node 的标签是否满足 Pod 的 nodeSelector 属性 hard 选择器（requiredDuringSchedulingIgnoredDuringExecution）需求。
• PodFirsResources: 检查 Node 的资源是否满足Pod的需求。
• Taint & Toleration: Pod容忍度设置 NoSchedule 或 NoExecute，用来避免Pod被分配到不合适的节点上。

Priorities，优选函数

将Predicate函数执行结果进行计算评分后排序，得分最高 Node 进行 Pod调度。

• LeastRequested: 按空闲度（空闲总量/总容量）进行Node排序。
• BalanceResourceAllocation: 资源均匀分布，必须与 LeastRequested 同时使用。
• SelectorSpreading: 对于属于同一个service、rc的 Pod，尽量分散在不同的主机上。
• NodeAffinity: 检查Node的标签是否满足 Pod 的 nodeSelector 属性 soft选择器（preferresDuringSchedulingIgnoreDuringExecution）需求。
• Taint & Toleration: Pod容忍度设置PreferNoSchedule。