Kubernetes权威指南——核心组件运行机制（API Server原理解析）

核心组件运行机制1、Kubernetes API Server原理解析1.1、Kubernetes API Server概述1.2、API Server架构解析1.3、独特的Kubernetes Proxy API接口1.4、集群功能模块之间的通信1、Kubernetes API Server原理解析总体来看Kubernetes API Server的核心功能是提供Kubernetes各类资源对象如Pod、RC、Service等的增、删、改、查及Watch等HTTP Rest接口成为集群内各个功能模块之间数据交互和通信的中心枢纽是整个系统的数据总线和数据中心。除此之外它还有以下一些功能特性。1是集群管理的API入口。2是资源配额控制的入口。3提供了完备的集群安全机制。1.1、Kubernetes API Server概述Kubernetes API Server通过一个名为kube-apiserver的进程提供服务该进程运行在Master上。在默认情况下kube-apiserver进程在本机的8080端口对应参数–insecure-port提供REST服务。我们可以同时启动HTTPS安全端口–secure-port6443来启动安全机制加强REST API访问的安全性。我们通常可以通过命令行工具kubectl来与KubernetesAPI Server交互它们之间的接口是RESTful API。为了测试和学习Kubernetes API Server所提供的接口我们也可以使用curl命令行工具进行快速验证。比如登录Master并运行下面的curl命令得到以JSON方式返回的Kubernetes API的版本信息# curl localhost:8080/api{kind:APIVersions,versions:[v1],serverAddressByClientCIDRs:[{clientCIDR:0.0.0.0/0,serverAddress:192.168.18.131:6443}]}可以运行下面的命令查看Kubernetes 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进程启动一个内部代理来实现。运行下面的命令在8001端口启动代理并且拒绝客户端访问RC的API# kubectl proxy --reject-paths^/api/v1/replicationcontrollers --port8001--v2Starting to serve on127.0.0.1:8001运行下面的命令进行验证# curl localhost:8001/api/v1/replicationcontrollersh3Unauthorized/h3kubectl proxy具有很多特性最实用的一个特性是提供简单有效的安全机制比如在采用白名单限制非法客户端访问时只需增加下面这个参数即可--accept-hosts^localhost$,^127\\.0\\.0\\.1$,^\\[::1\\]$最后一种方式是通过编程方式调用Kubernetes APIServer。具体使用场景又细分为以下两种。第1种使用场景运行在Pod里的用户进程调用Kubernetes API通常用来实现分布式集群搭建的目标。比如下面这段来自谷歌官方的Elasticsearch集群例子中的代码Pod在启动的过程中通过访问Endpoints的API找到属于elasticsearch-logging这个Service的所有Pod副本的IP地址用来构建集群如图所示。在上述使用场景中Pod中的进程如何知道API Server的访问地址呢答案很简单Kubernetes API Server本身也是一个Service它的名称就是kubernetes并且它的Cluster IP地址是Cluster IP地址池里的第1个地址另外它所服务的端口是HTTPS端口443通过kubectl getservice命令可以确认这一点# kubectl get serviceNAME CLUSTER-IP EXTERNAL-IP PORT(S)AGE kubernetes169.169.0.1none443/TCP 30d第2种使用场景开发基于Kubernetes的管理平台。比如调用Kubernetes API来完成Pod、Service、RC等资源对象的图形化创建和管理界面此时可以使用Kubernetes及各开源社区为开发人员提供的各种语言版本的ClientLibrary。后面会介绍通过编程方式访问API Server的一些细节技术。由于API Server是Kubernetes集群数据的唯一访问入口因此安全性与高性能就成为API Server设计和实现的两大核心目标。通过采用HTTPS安全传输通道与CA签名数字证书强制双向认证的方式API Server的安全性得以保障。此外为了更细粒度地控制用户或应用对Kubernetes资源对象的访问权限Kubernetes启用了RBAC访问控制策略之后会深入讲解这一安全策略。API Server的性能是决定Kubernetes集群整体性能的关键因素因此Kubernetes的设计者综合运用以下方式来最大程度地保证API Server的性能。1API Server拥有大量高性能的底层代码。在APIServer源码中使用协程Coroutine队列Queue这种轻量级的高性能并发代码使得单进程的API Server具备了超强的多核处理能力从而以很快的速度并发处理大量的请求。2普通List接口结合异步Watch接口不但完美解决了Kubernetes中各种资源对象的高性能同步问题也极大提升了Kubernetes集群实时响应各种事件的灵敏度。3采用了高性能的etcd数据库而非传统的关系数据库不仅解决了数据的可靠性问题也极大提升了APIServer数据访问层的性能。在常见的公有云环境中一个 3节点的etcd集群在轻负载环境中处理一个请求的时间可以低于1ms在重负载环境中可以每秒处理超过30000个请求。正是由于采用了上述提升性能的方法API Server可以支撑很大规模的Kubernetes集群。截至1.13版本时Kubernetes已经可以支持最多5000节点规模的集群同时Kubernetes API Server也淘汰了etcd 2.0只支持etcd3.0以上版本。1.2、API Server架构解析API Server的架构从上到下可以分为以下几层如图所示。1API层主要以REST方式提供各种API接口除了有Kubernetes资源对象的CRUD和Watch等主要API还有健康检查、UI、日志、性能指标等运维监控相关的API。Kubernetes从1.11版本开始废弃Heapster监控组件转而使用Metrics Server提供Metrics API接口进一步完善了自身的监控能力。2访问控制层当客户端访问API接口时访问控制层负责对用户身份鉴权验明用户身份核准用户对Kubernetes资源对象的访问权限然后根据配置的各种资源访问许可逻辑Admission Control​判断是否允许访问。3注册表层Kubernetes把所有资源对象都保存在注册表Registry中针对注册表中的各种资源对象都定义了资源对象的类型、如何创建资源对象、如何转换资源的不同版本以及如何将资源编码和解码为JSON或ProtoBuf格式进行存储。4etcd数据库用于持久化存储Kubernetes资源对象的KV数据库。etcd的watch API接口对于API Server来说至关重要因为通过这个接口API Server创新性地设计了List-Watch这种高性能的资源对象实时同步机制使Kubernetes可以管理超大规模的集群及时响应和快速处理集群中的各种事件。从本质上看API Server与常见的MIS或ERP系统中的DAO模块类似可以将主要处理逻辑视作对数据库表的CRUD操作。这里解读API Server中资源对象的List-Watch机制。下图以一个完整的Pod调度过程为例对API Server的List-Watch机制进行说明。首先借助etcd提供的Watch API接口API Server可以监听Watch在etcd上发生的数据操作事件比如Pod创建事件、更新事件、删除事件等在这些事件发生后etcd会及时通知API Server。图5.3中API Server与etcd之间的交互箭头表明了这个过程当一个ReplicaSet对象被创建并被保存到etcd中后图中的2. Create RepliatSet箭头​etcd会立即发送一个对应的Create事件给APIServer图中的3. Send RepliatSet Create Event箭头​与其类似的6、7、10、11箭头都是针对Pod的创建、更新事件的。然后为了让Kubernetes中的其他组件在不访问底层etcd数据库的情况下也能及时获取资源对象的变化事件API Server模仿etcd的Watch API接口提供了自己的Watch接口这样一来这些组件就能近乎实时地获取它们感兴趣的任意资源对象的相关事件通知了。图中 controller-manager、scheduler、kublet等组件与APIServer之间的3个标记有List-Watch的虚框表明了这个过程。同时在监听自己感兴趣的资源的时候客户端可以增加过滤条件以List-Watch 3为例node1节点上的kubelet进程只对自己节点上的Pod事件感兴趣。最后Kubernetes List-Watch用于实现数据同步的代码逻辑。客户端首先调用API Server的List接口获取相关资源对象的全量数据并将其缓存到内存中然后启动对应资源对象的Watch协程在接收到Watch事件后再根据事件的类型比如新增、修改或删除对内存中的全量资源对象列表做出相应的同步修改从实现上来看这是一种全量结合增量的、高性能的、近乎实时的数据同步方式。接下来说说API Server中的另一处精彩设计。我们知道对于不断迭代更新的系统对象的属性一定是在不断变化 的API接口的版本也在不断升级此时就会面临版本问题即同一个对象不同版本之间的数据转换问题及API接口版本的兼容问题。后面这个问题解决起来比较容易即定义不同的API版本号比如v1alpha1、v1beta1来加以区分但前面的问题就有点麻烦了比如数据对象经历v1alpha1、v1beta1、v1beta1、v1beta2等变化后最终变成v1版本此时该数据对象就存在5个版本如果这5个版本之间的数据两两直接转换就存在很多种逻辑组合变成一种典型的网状网络如下图所示为此我们不得不增加很多重复的转换代码。上述直接转换的设计模式还存在另一个不可控的变数即每增加一个新的对象版本之前每个版本的对象就都需要增加一个到新版本对象的转换逻辑。如此一来对直接转换的实现就更难了。于是API Server针对每种资源对象都引入了一个相对不变的internal版本每个版本只要支持转换为internal版本就能够与其他版本进行间接转换。于是对象版本转换的拓扑图就简化成了如下图所示的星状图。本节最后简单说说Kubernetes中的CRD在API Server中的设计和实现机制。根据Kubernetes的设计每种官方内建的资源对象如Node、Pod、Service等的实现都包含以下主要功能。1资源对象的元数据Schema的定义可以将其理解为数据库Table的定义定义了对应资源对象的数据结构官方内建资源对象的元数据定义是固化在源码中的。2资源对象的校验逻辑确保用户提交的资源对象的属性的合法性。3资源对象的CRUD操作代码可以将其理解为数据库表的CRUD代码但比后者更难因为API Server对资源对象的CRUD操作都会保存到etcd数据库中对处理性能的要求也更高还要考虑版本兼容性和版本转换等复杂问题。4资源对象相关的“自动控制器”​如RC、Deployment等资源对象背后的控制器​这是很重要的一个功能。因为Kubernetes是一个以自动化为核心目标的平台用户给出期望的资源对象声明运行过程中则由资源背后的“自动控制器”负责确保对应资源对象的数量、状态、行为都始终符合用户的预期。类似地每个自定义CRD的开发人员都需要实现上面这些功能。为了减小编程的难度与工作量API Server的设计者们做出了大量的努力使得上面前3个功能无须编程实现直接编写YAML定义文件即可实现。对于唯一需要编程的第4个功能来说由于API Server提供了大量的基础API库特别是易用的List-Watch的编程框架也使得CRD自动控制器的编程难度大大减小。1.3、独特的Kubernetes Proxy API接口前面讲到Kubernetes API Server最主要的REST接口是资源对象的增、删、改、查接口除此之外它还提供了一类很特殊的REST接口—Kubernetes Proxy API接口这类接口的作用是代理REST请求即KubernetesAPI 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/#和anaconda/等/api/v1/proxy/nodes/{name}/metrics# 列出和该节点相关的Metrics信息/api/v1/proxy/nodes/{name}/runningpods# 列出节点内运行中的Pod信息/api/v1/proxy/nodes/{name}/debug/pprof# 列出节点内当前Web服务的状态# 包括CPU占用情况和内存使用情况等接下来说说Kubernetes Proxy API里关于Pod的相关接口通过这些接口我们可以访问Pod里某个容器提供的服务如Tomcat在8080端口的服务​/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在上面的4个接口里后面两个接口的功能与前面两个完全一样只是写法不同。下面用第1章Java Web例子中的Tomcat Pod来说明上述Proxy接口的用法。首先得到Pod的名称# kubectl get podsNAME READY STATUS RESTARTS AGE mysql-c95jc1/1 Running08d myweb-g9pmm1/1 Running08d然后运行下面的命令会输出Tomcat的首页即相当于访问http://localhost:8080/# curlhttp://localhost:8080/api/v1/proxy/namespaces/default/pods/myweb-g9pmm/我们也可以在浏览器中访问上面的地址比如Master的IP地址是192.168.18.131我们在浏览器中输入http://192.168.18.131:8080/api/v1/proxy/namespaces/default/pods/myweb-g9pmm/就能够访问Tomcat首页了而如果输入/api/v1/proxy/namespaces/default/pods/myweb-g9pmm/demo就能访问Tomcat中Demo应用的页面了。看到这里你可能明白Pod的Proxy接口的作用和意义了在Kubernetes集群之外访问某个Pod容器的服务HTTP服务时可以用Proxy API实现这种场景多用于管理目的比如逐一排查Service的Pod副本检查哪些Pod的服务存在异常。最后说说Service。Kubernetes Proxy API也有Service的Proxy接口其接口定义与Pod的接口定义基本一样/api/v1/proxy/namespaces/{namespace}/services/{name}。比如若我们想访问MyWeb这个Service则可以在浏览器里输入http://192.168.18.131:8080/api/v1/proxy/namespaces/default/services/myweb/demo/。1.4、集群功能模块之间的通信从下图中可以看出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进程与APIServer的交互。kube-controller-manager中的NodeController模块通过API Server提供的Watch接口实时监控Node的信息并做相应处理。还有一个比较重要的交互场景是kube-scheduler与APIServer的交互。Scheduler通过API Server的Watch接口监听到新建Pod副本的信息后会检索所有符合该Pod要求的Node列表开始执行Pod调度逻辑在调度成功后将Pod绑定到目标节点上。为了缓解集群各模块对API Server的访问压力各功能模块都采用缓存机制来缓存数据。各功能模块定时从APIServer获取指定的资源对象信息通过List-Watch方法​然后将这些信息保存到本地缓存中功能模块在某 些情况下不直接访问API Server而是通过访问缓存数据来间接访问API Server。