K8S中的ApiServer的通信原理
K8S中的ApiServer的通信原理ApiServer的主要功能是 对k8s集群的资源进行CRUD操作,所有的对k8s集群的操作必须通过ApiServer,ApiServer通过对外提供restful类型的接口向外发布服务;内部kubectl命令也是通过ApiServer执行。其实ApiServer是通过一个名为kube-apiServer的Service提供服务的,也就是说ApiServer本
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
传递过程
ApiServer
作为k8s
集群的核心,协调各个模块信息的传递和协调,各个node
每隔一段时间,将自己的信息发送给ApiServer
,而ApiServer
本身不存储信息,就每个node
的各种信息存到etcd
中,当调用ApiServer
获取信息的时候,ApiServer
就会进入etcd
中获取信息,反馈给用户。
ApiServer
是通过RPC
与etcd
进行通信。客户端不可以绕过ApiServer
,直接与etcd
进行通信
k8s
创建一个pod
的完整的过程
- 用户通过
Rest Api
发起创建Pod
的请求 Api-server
接收请求并且将其写入etcd
kube-scheduluer
检测到为绑定Node
的Pod
,开始调度并更新Pod
的Node
的绑定,通知apiServer
将其写入etcd
kubelet
通过watch、apiServer
检测到有新的Pod
调度过来,通过container runtime
运行该pod
kubelet
通过container
运行该Pod
list-watch
机制
客户端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
的压力
参考
更多推荐
所有评论(0)