Kubernetes系列06：Kubernetes API Server原理分析

总体来看，kubernetes API Server 的核心功能是提供了各类资源对象的增删改查及watch等HTTP Rest接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。除此之外，它还有以下一些功能特性。
（1）是集群管理的API入口
（2）是资源配额控制的入口
（3）提供了完备的集群安全机制

1.kubernetes API Server概述
kubernetes API Server通过一个名为kube-apiserver的进程提供服务，该进程运行在Master节点上，在默认情况下，kube-apiserver进程在本机的8080端口（对应参数--insecure-port）提供REST服务。我们可以同时启动HTTPS安全端口（--secure-pot=6443）来启动安全机制，加强REST API访问的安全性。

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

可以运行命令，查看kubernetes API Server目前所支持的资源对象的种类：
#curl localhost:8080/api/v1

返回集群中的Pod列表、Service列表、RC列表
#curl localhost:8080/api/v1/pods
#curl localhost:8080/api/v1/services
#curl localhost:8080/api/v1/replicationcontrollers


2.独特的kubernetes Proxy API 接口
kubernetes API Server主要的REST接口是资源对象的增删改查，除此还提供一类很特殊的REST接口--kubernetes Proxy API接口，这类接口的作用是代理REST请求，即kubernetes API Server把收到的REST请求转发到某个Node上kubelet守护进程的REST端口上，由该Kubelet进程负责响应。

首先，我们来说说kubernetes Proxy API里关于Node的相关接口，该接口的REST路径为/api/v1/proxy/nodes/{name},其中{name}为节点的名称或者IP，包括接口：
/api/v1/proxy/nodes/{name}/pods/  #列出指定节点内所有Pod的信息
/api/v1/proxy/nodes/{name}/stats/ #列出指定节点内物力资源的统计信息
/api/v1/proxy/nodes/{name}/spec/  #列出指定节点的概要信息

例：当前Node节点的名字为k8s-node-1，用下面的命令可获得该节点上所有运行的Pod：
#curl localhost:8080/api/v1/proxy/nodes/k8s-node-1/pods

需要说明的是：这里获取的Pod的信息数据来自Node而非etcd数据库，所以两者可能在某些时间点会有偏差。此外，如果kubelet进程在启动时包含--enable-debugging-handlers=true参数，那么kubernetes Proxy API还会增加下面的接口：
/api/v1/proxy/nodes/{name}/run #在节点上运行某个容器
/api/v1/proxy/nodes/{name}/exec #在节点上的某个容器中运行某条命令
/api/v1/proxy/nodes/{name}/attach #在节点上attach某个容器
/api/v1/proxy/nodes/{name}/portForward #实现节点上的Pod端口转发
/api/v1/proxy/nodes/{name}/logs #列出节点的各类日志信息，如tallylog、lastlog、wtmp、ppp/、rhsm/、audit/、tuned/和annaconda/等
/api/v1/proxy/nodes/{name}/metrics #列出和该节点相关的Metrics信息
/api/v1/proxy/nodes/{name}/runningpods #列出节点内运行中的Pod信息
/api/v1/proxy/nodes/{name}/debug/pprof #列出节点内当前web服务的状态，包括CPU占用情况和内存使用情况

接下来，关于Pod的相关接口
/api/v1/proxy/namespaces/{namespace}/pods/{name}/{path:*} #访问Pod的某个服务接口
/api/v1/proxy/namespaces/{namespace}/pods/{name} #访问pod
/api/v1/namespaces/{namespace}/pods/{name}/proxy/{path:*} #访问Pod的某个服务接口
/api/v1/namespaces/{namespace}/pods/{name}/proxy #访问Pod
后面两个接口功能与前面两个完全一样，只是写法不同。

3.集群功能模块之间的通信
kubernetes API Server作为集群的核心，负责集群各功能模块之间的通信。集群内的各个功能模块通过API Server将信息存入etcd，当需要获取和操作这些数据时，则通过API Server提供的REST接口（用GET、LIST、WATCH方法）实现，从而实现各模块之间的信息交互。

常见的一个交互场景是kubelet进程与API server的交互。每个Node节点上的kubelet每隔一个时间周期，就会调用一次API Server的REST接口报告自身状态，API Server接收到这些信息后，将节点状态信息更新到etcd中。此外，kubelet也通过API Server的Watch接口监听Pod信息，如果监听到新的Pod副本被调度绑定到本节点，则执行Pod对应的容器的创建和启动逻辑；如果监听到的Pod对象被删除，则删除本节点上的相应Pod容器；如果监听到修改Pod信息，则kubelet监听到变化后，会相应地修改本节点的Pod 容器。

另外一个交互场景是kube-controller-manager进程与API Server的交互。kube-controller-manager中的Node Controller模块通过API Server提供的Wacth接口，实时监控Node的信息，并做相应处理。

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

为了缓解集群各模块对API Server的访问压力，各功能模块都采用缓存机制来缓存数据，各功能模块定时从API Server获取指定的资源对象信息（通过LIST及WATCH方法），然后将这些信息保存到本地缓存，功能模块在某些情况下不直接访问API Server，而是通过访问缓存数据来间接访问API Server。