K8S中的ApiServer的通信原理

ApiServer的主要功能是 对k8s集群的资源进行CRUD操作，所有的对k8s集群的操作必须通过ApiServer，ApiServer通过对外提供restful类型的接口向外发布服务；内部kubectl命令也是通过ApiServer执行。其实ApiServer是通过一个名为kube-apiServer的Service提供服务的，也就是说ApiServer本质上就是一个Service，这样就可以很好的解释了如果存在多个master节点，ApiService提供服务的方式。关于ApiServer的详细信息，可以通过kubectl get svc进行查询，也可以找到对应yaml文件进行修改来让ApiService达到我们想要的效果

ApiServer和其他node进行交互的方式同样是基于http，ApiServer不仅有提供给外部交互的接口，也有和非主节点node交互的接口kubernetes Proxy Api，这个接口的作用是将ApiServer收到的请求，发送给各个节点的kubelet守护进程的接口上获取相应node上的信息

ApiServer作为k8s集群的核心，协调各个模块信息的传递和协调，各个node每隔一段时间，将自己的信息发送给ApiServer，而ApiServer本身不存储信息，就每个node的各种信息存到etcd中，当调用ApiServer获取信息的时候，ApiServer就会进入etcd中获取信息，反馈给用户。

ApiServer是通过RPC与etcd进行通信。客户端不可以绕过ApiServer，直接与etcd进行通信

用户通过Rest Api发起创建Pod的请求Api-server接收请求并且将其写入etcdkube-scheduluer检测到为绑定Node的Pod，开始调度并更新Pod的Node的绑定，通知apiServer将其写入etcdkubelet通过watch、apiServer检测到有新的Pod调度过来，通过container runtime运行该podkubelet通过container运行该Pod

客户端kubelet/scheduler/controller-manager通过ApiServer的list-watch机制监听etcd中资源的变更事件

list-watch分成list和watch

list 就是列出资源的信息，基于http短链接实现watch就是检测资源的变化的，基于http长连接实现

watch是如何通过http长连接收取apiServer发来的资源变更事件呢？

Chunked transfer encoding（分块传输编码）

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

当客户端调用watchAPI时，apiService在response的http header中设置Transfer-Encoding的值为chunked表示采用分块传输编码，客户端收到该信息后，便和服务端保持连接，等待下一个数据块。

list-watch机制的过程远远不止如此，list-watch是k8s的核心之一，list-watch的系统有很多优秀的特点

消息可靠性

list和watch一起保证了消息的可靠性，避免因消息丢失而造成状态不一致的场景，仅用watch是不能保障的

消息实时性

每当apiServer的资源产生状态变更事件，都会将事件及时推送给客户端，从而保障消息的实时性

消息顺序性

k8s的每个资源都带一个resourceVersion的标签，这个标签是递增的数字，这样就可以保证消息的最终一致性

高性能

避免了频繁地周期性轮询，减少了apiServer的压力

理解 K8S 的设计精髓之 List-Watch机制和Informer模块 - 知乎 (zhihu.com)