k8s-API server原理分析

我们都知道， k8s的API server核心功能是提供了k8s各类资源对象（Pod，RC，service）的增，删，改，查及HTTP REST接口。

server是通过一个名为kube-apiserver的进程提供服务。该进程运行在master节点上，默认情况下，在本机8080端口提供REST服务。

通常我们可以通过命令行工具kubectl来与API server交互。它们之间的接口是REST调用。为了测试和学习API server所提供的接口，也可以使用curl命令行工具进行快速验证。

比如我们登录master节点，运行下面的curl命令，得到以json方式返回的API的版本信息：

curl localhost:8080/api

可以运行下面命令，查看API server目前所支持的资源对象的种类：

curl localhost:8080/api/v1

根据以上命令的输出，可以运行下面的curl命令，分别返回集群中的pod列表，service列表，RC列表等：

curl localhost:8080/api/v1/pods

curl localhost:8080/api/v1/services

curl localhost:8080/api/v1/replicationcontrollers

如果我们只想对外暴露部分REST服务，则可以在master或其他任何节点上通过运行kubectl proxy进程启动一个内部代理来实现。

kubectl proxy --reject-paths="^/api/v1/replicationcontrollers" --port=8001 --v=2

然后运行下面命令验证：

curl localhost:8080/api/v1/replicationcontrollers

会显示如下：

也就是说可以通过proxy提供简单有效的安全机制。

最后一种方式是可以通过编程的方式调用API server。

 

集群功能模块之间的通信

如下图所示：

API server作为集群的核心，负责各个功能模块之间的通信。集群中各个模块通过API server将信息存入etcd，当需要获取和操作这些数据时，则通过API server提供的REST接口来实现，从而实现各模块之间的信息交互。

常见的一个交互场景是kubelet与API server交互。每个node节点上的kubelet每隔一个时间周期，会调用一次API server的REST接口报告自身状态。API server接受到这些信息，更新至etcd中，此外，kubelet也通过server的watch接口监听pod信息，若监听到新的pod副本被调度绑定到本节点，则执行pod对应的容器创建和启动。如果监听到pod对象被删除，则删除本节点上对应的pod容器。

另一个交互场景是kube-controller-manager进程与API server的交互。前者的Node controller模块通过API server提供的watch接口。实时监控Node的信息。

还有一个比较重要的交互场景就是kube-scheduler与api server交互，当前者通过server的watch接口监听到新建pod副本的信息后，它会检索所有符合该pod要求的Node列表，开始执行pod调度逻辑，调度成功后将pod绑定到目标节点上。