k8s核心组件

Kubernetes API Server

由于API Server是Kubernetes集群数据的唯一访问入口，因此安全性与高性能成为API Server设计和实现的两大核心目标。通过采用HTTPS安全传输通道与CA签名数字证书强制双向认证的方式，API Server的安全性得以保障。此外，为了更细粒度地控制用户或应用对Kubernetes资源对象的访问权限，Kubernetes启用了RBAC访问控制策略。

1. API Server拥有大量高性能的底层代码。在API Server源码中使用协程+队列这种轻量级的高性能并发代码，使得单进程的API Server具备超强的多核处理能力，从而以很快的速度并发处理大量的请求。
   
   

2. 普通List接口结合异步Watch接口，不但完美解决了Kubernetes中各种资源对象的高性能同步问题，也极大提升了Kubernetes集群实时响应各种事件的灵敏度。
   
   

3. 采用了高性能的etcd数据库而非传统的关系数据库，不仅解决了数据的可靠性问题，也极大提升了API Server数据访问层的性能。在常见的公有云环境中，一个3节点的etcd集群在轻负载环境中处理一个请求的时间可以少于1ms，在重负载环境中可以每秒处理超过30000个请求。

API Server架构解析

API Server架构从上到下可以分为以下几层:

1. API层：主要以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格式进行存储。
   
   

4. etcd数据库：用于持久化存储Kubernetes资源对象的KV数据库。etcd的Watch API接口对于API Server来说至关重要，因为通过这个接口，API Server创新性地设计了List-Watch这种高性能的资源对象实时同步机制，使Kubernetes可以管理超大规模的集群，及时响应和快速处理集群中的各种事件。

API Server与常见的MIS或ERP系统中的DAO模块类似，可以将主要处理逻辑视作对数据库表的CRUD操作。这里解读APIServer中资源对象的List-Watch机制。

以一个完整的Pod调度过程为例

首先，借助etcd提供的Watch API接口，API Server可以监听（Watch）在etcd上发生的数据操作事件，比如Pod创建事件、更新事件、删除事件等，在这些事件发生后，etcd会及时通知API Server。图5.3中API Server与etcd之间的交互箭头表明了这个过程：当一个ReplicaSet对象被创建并保存到etcd中后（图中的2.Create RepliatSet箭头），etcd会立即发送一个对应的Create事件给API Server（图中的3.Send RepliatSet Create Event箭头），与其类似的6、7、10、11箭头都针对Pod的创建、更新事件。

然后，为了让Kubernetes中的其他组件在不访问底层etcd数据库的情况下，也能及时获取资源对象的变化事件，API Server模仿etcd的Watch API接口提供了自己的Watch接口，这样一来，这些组件就能近乎实时地获取自己感兴趣的任意资源对象的相关事件通知了。图5.3中的controller-manager、scheduler、kubelet等组件与API Server之间的3个标记为“List-Watch”的虚线框表明了这个过程。同时，在监听自己感兴趣的资源时，客户端可以增加过滤条件，以List-Watch 3为例，node1节点上的kubelet进程只对自己节点上的Pod事件感兴趣。

最后，Kubernetes List-Watch用于实现数据同步的代码逻辑。客户端首先调用API Server的List接口获取相关资源对象的全量数据并将其缓存到内存中，然后启动对应资源对象的Watch协程，在接收到Watch事件后，再根据事件的类型（比如新增、修改或删除）对内存中的全量资源对象列表做出相应的同步修改。从实现上来看，这是一种全量结合增量的、高性能的、近乎实时的数据同步方式。

Kubernetes Proxy API接口

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

集群功能模块之间的通信

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提供的Watch接口实时监控Node的信息，并做相应的处理。

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

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

API Server网络隔离的设计

API Server Network Proxy的核心设计思想是将API Server放置在一个独立的网络中，与Node节点的网络相互隔离，然后增加独立的Network Proxy进程来解决这两个网络直接的连通性（Connectivity）问题

Controller Manager原理解析

一般来说，智能系统和自动系统通常会通过一个“操作系统”不断修正系统的工作状态。在Kubernetes集群中，每个Controller都是这样的一个“操作系统”，它们通过API Server提供的（List-Watch）接口实时监控集群中特定资源的状态变化，当发生各种故障导致某资源对象的状态变化时，Controller会尝试将其状态调整为期望的状态。比如当某个Node意外宕机时，Node Controller会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态下。Controller Manager是Kubernetes中各种操作系统的管理者，是集群内部的管理控制中心，也是Kubernetes自动化功能的核心。

Controller Manager结构图

副本调度控制器

在Kubernetes中存在两个功能相似的副本控制器：Replication
Controller及Deployment Controller。Replication Controller简写为RC

Replication Controller的核心作用是确保集群中某个RC关联的Pod副本数量在任何时候都保持预设值。如果发现Pod的副本数量超过预设值，则Replication Controller会销毁一些Pod副本；反之，ReplicationController会自动创建新的Pod副本，直到符合条件的Pod副本数量达到预设值。需要注意：只有当Pod的重启策略是Always时（RestartPolicy=Always），Replication Controller才会管理该Pod的操作（例如创建、销毁、重启等）。在通常情况下，Pod对象被成功创建后都不会消失，唯一的例外是Pod处于succeeded或failed状态的时间过长（超时参数由系统设定），此时该Pod会被系统自动回收，管理该Pod的副本控制器将在其他工作节点上重新创建、运行该Pod副本。

RC中的Pod模板就像一个模具，模具制作出来的东西一旦离开模具，它们之间就再也没关系了。同样，一旦Pod被创建完毕，无论模板、如何变化，甚至换成一个新的模板，也不会影响到已经创建的Pod了。

此外，Pod可以通过修改它的标签来脱离RC的管控，该方法可以用于将Pod从集群中迁移、数据修复等的调试。对于被迁移的Pod副本，RC会自动创建一个新的副本替换被迁移的副本。随着Kubernetes的不断升级，旧的RC已不能满足需求，所以有了
Deployment。Deployment可被视为RC的替代者，RC及对应的Replication Controller已不再升级、维护，Deployment及对应的Deployment Controller则不断更新、升级新特性。

Deployment Controller在工作过程中实际上是在控制两类相关的资源对象：Deployment及ReplicaSet。在我们创建Deployment资源对象之后，Deployment Controller也默默创建了对应的ReplicaSet，Deployment的滚动升级也是Deployment Controller通过自动创建新的ReplicaSet来支持的。

Deployment Controller的作用

1. 重新调度（Rescheduling）。如前面所述，不管想运行1个副本还是1000个副本，副本控制器都能确保指定数量的副本存在于集群中，即使发生节点故障或Pod副本被终止运行等意外状况。
   
   

2. 弹性伸缩（Scaling）。手动或者通过自动扩容代理修改副本控制器spec.replicas属性的值，非常容易实现增加或减少副本的数量。
   
   

3. 滚动更新（Rolling Updates）。副本控制器被设计成通过逐个替换Pod来辅助服务的滚动更新。

Node Controller

kubelet进程在启动时通过API Server注册自身节点信息，并定时向API Server汇报状态信息，API Server在接收到这些信息后，会将这些信息更新到etcd中。在etcd中存储的节点信息包括节点健康状况、节点资源、节点名称、节点地址信息、操作系统版本、Docker版本、kubelet版本等。节点健康状况包含就绪（True）、未就绪（False）、未知（Unknown）三种。

Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群中各个Node的相关控制功能

Node Controller的核心工作流程:

（1）Controller Manager在启动时如果设置了--cluster-cidr参数，那么为每个没有设置Spec.PodCIDR的Node都生成一个CIDR地址，并用该CIDR地址设置节点的Spec.PodCIDR属性，这样做的目的是防止不同节点的CIDR地址发生冲突。

（2）逐个读取Node信息，多次尝试修改nodeStatusMap中的节点状态信息，将该节点信息和在Node Controller的nodeStatusMap中保存的节点信息做比较。如果判断出没有收到kubelet发送的节点信息、第1次收到节点kubelet发送的节点信息，或在该处理过程中节点状态变成非健康状态，则在nodeStatusMap中保存该节点的状态信息，并用Node Controller所在节点的系统时间作为探测时间和节点状态变化时间。如果判断出在指定时间内收到新的节点信息，且节点状态发生变化，则在nodeStatusMap中保存该节点的状态信息，并用Node Controller所在节点的系统时间作为探测时间和节点状态变化时间。如果判断出在指定时间内收到新的节点信息，但节点状态没发生变化，则在nodeStatusMap中保存该节点的状态信息，并用Node Controller所在节点的系统时间作为探测时间，将上次节点信息中的节点状态变化时间作为该节点的状态变化时间。如果判断出在某段时间（gracePeriod）内没有收到节点状态信息，则设置节点状态为“未知”，并且通过API Server保存节点状态。

（3）逐个读取节点信息，如果节点状态变为非就绪状态，则将节点加入待删除队列，否则将节点从该队列中删除。如果节点状态为非就绪状态，且系统指定了Cloud Provider，则Node Controller调用Cloud Provider查看节点，若发现节点故障，则删除etcd中的节点信息，并删除与该节点相关的Pod等资源的信息。

ResourceQuota Controller

Kubernetes也提供了ResourceQuota Controller（资源配额管理）这一高级功能，资源配额管理确保指定的资源对象在任何时候都不会超量占用系统物理资源，避免由于某些业务进程在设计或实现上的缺陷导致整个系统运行紊乱甚至意外宕机，对整个集群的平稳运行和稳定性都有非常重要的作用。

目前Kubernetes支持如下三个层次的资源配额管理。

1. 容器级别，可以对CPU和Memory进行限制。
2. Pod级别，可以对一个Pod内所有容器的可用资源进行限制。
3. Namespace级别，为Namespace（多租户）级别的资源限制，包括：Pod数量、Replication Controller数量、Service数量、ResourceQuota数量、Secret数量和可持有的PV数量

Namespace Controller

用户通过API Server可以创建新的Namespace并将其保存在etcd中，Namespace Controller定时通过API Server读取这些Namespace的信息。如果Namespace被API标识为优雅删除（通过设置删除期限实现，即设置DeletionTimestamp属性），则将该NameSpace的状态设置成Terminating并保存在etcd中。同时，Namespace Controller删除该Namespace下的ServiceAccount、RC、Pod、Secret、PersistentVolume、ListRange、ResourceQuota和Event等资源对象。

Service Controller与Endpoints Controller

Endpoints表示一个Service对应的所有Pod副本的访问地址，Endpoints Controller就是负责生成和维护所有Endpoints对象的控制器。

Endpoints Controller负责监听Service和对应的Pod副本的变化，如果监测到Service被删除，则删除和该Service同名的Endpoints对象。如果监测到新的Service被创建或者修改，则根据该Service信息获得相关的Pod列表，然后创建或者更新Service对应的Endpoints对象。如果监测到Pod的事件，则更新它所对应的Service的Endpoints对象（增加、删除或者修改对应的Endpoint条目）。

那么，Endpoints对象是在哪里被使用的呢？答案是每个Node上的kube-proxy进程，kube-proxy进程获取每个Service的Endpoints，实现了Service的负载均衡功能。

接下来说说Service Controller的作用，它其实是Kubernetes集群与外部云平台之间的一个接口控制器。Service Controller监听Service的变化，如果该Service是一个LoadBalancer类型的Service（externalLoadBalancers=true），则Service Controller确保该Service对应的LoadBalancer实例在外部的云平台上被相应地创建、删除及更新路由转发表（根据Endpoints的条目）。

Scheduler原理解析

Kubernetes Scheduler是负责Pod调度的进程（组件），随着Kubernetes功能的不断增强和完善，Pod调度也变得越来越复杂，Kubernetes Scheduler内部的实现机制也在不断优化，从最初的两阶段调度机制（Predicates &Priorities）发展到后来的升级版的调度框架（Scheduling Framework），以满足越来越复杂的调度场景。

Scheduler的调度流程

Kubernetes Scheduler的作用是将待调度的Pod（API新创建的Pod、Controller Manager为补足副本而创建的Pod等）按照特定的调度算法和调度策略绑定（Binding）到集群中某个合适的Node上，并将绑定信息写入etcd中。在整个调度过程中涉及三个对象，分别是待调度Pod列表、可用Node列表及调度算法和策略。简单地说，就是通过调度算法为待调度Pod列表中的每个Pod都从Node列表中选择一个最适合的Node。

随后，目标节点上的kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，然后获取对应的Pod清单，下载Image镜像并启动容器。

完整的流程

Scheduler Framework

新的Scheduler Framework是在旧流程的基础上增加了一些扩展点（基于调度Stage的扩展点），同时支持用户以插件的方式（Plugin）进行扩展。

新的调度流程如图

kubelet运行机制解析

在Kubernetes集群中，在每个Node（又称Minion）上都会启动一个kubelet服务进程。该进程用于处理Master下发到本节点的任务，管理Pod及Pod中的容器。每个kubelet进程都会在API Server上注册节点自身的信息，定期向Master汇报节点资源的使用情况，并通过cAdvisor监控容器和节点资源。

节点管理

节点通过设置kubelet的启动参数“--register-node”，来决定是否向API Server注册自己。如果该参数的值为true，那么kubelet将试着通过API Server注册自己。在自注册时，kubelet启动时还包含下列参数。

• --api-servers：API Server的位置。
• --kubeconfig：kubeconfig文件，用于访问API Server的安全配置文件。
• --cloud-provider：云服务商（IaaS）地址，仅用于公有云环境中。

kubelet在启动时通过API Server注册节点信息，并定时向API Server发送节点的新消息，API Server在接收到这些信息后，会将其写入etcd中。通过kubelet的启动参数--node-status-update-frequency可设置kubelet每隔多长时间向API Server报告节点的状态，默认为10s。

Pod管理

kubelet监听etcd，所有针对Pod的操作都会被kubelet监听。如果发现有新的绑定到本节点的Pod，则按照Pod清单的要求创建该Pod。如果发现本地的Pod需要被修改，则kubelet会做出相应的修改，比如在删除Pod中的某个容器时，会通过Docker Client删除该容器。如果发现本地的Pod需要被删除，则kubelet会删除相应的Pod，并通过DockerClient删除Pod中的容器。

kubelet读取监听到的信息，如果是创建和修改Pod任务，则做如下处理。

1. 为该Pod创建一个数据目录。
2. 从API Server中读取该Pod清单。
3. 为该Pod挂载外部卷（External Volume）。
4. 下载Pod用到的Secret。
5. 检查已经运行在节点上的Pod，如果该Pod没有容器或Pause容器（kubernetes/pause镜像创建的容器）没有启动，则先停止Pod里所有容器的进程。如果在Pod中有需要删除的容器，则删除这些容器。
6. 用kubernetes/pause镜像为每个Pod都创建一个容器。该Pause容器用于接管Pod中所有其他容器的网络。每创建一个新的Pod，kubelet都会先创建一个Pause容器，然后创建其他容器。kubernetes/pause镜像大概有200KB，是个非常小的容器镜像。
7. 为Pod中的每个容器都做如下处理。
   • 为容器计算一个哈希值，然后用容器的名称去查询对应Docker容器的哈希值。若查找到容器，且二者的哈希值不同，则停止Docker中容器的进程，并停止与之关联的Pause容器的进程；若二者相同，则不做任何处理。
   • 如果容器被终止，且容器没有指定的restartPolicy（重启策略），则不做任何处理。
   • 调用Docker Client下载容器镜像，调用Docker Client运行容器。

容器健康检查

Pod通过两类探针来检查容器的健康状态。一类是LivenessProbe探针，用于判断容器是否健康并反馈给kubelet，如果LivenessProbe探针探测到容器不健康，则kubelet将删除该容器，并根据容器的重启策略做相应的处理；如果一个容器不包含LivenessProbe探针，则kubelet会认为该容器的LivenessProbe探针返回的值永远是Success。

另一类是ReadinessProbe探针，用于判断容器是否启动完成，且准备接收请求。如果ReadinessProbe探针检测到容器启动失败，则Pod的状态将被修改，Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的IP地址的Endpoint条目。

cAdvisor资源监控

cAdvisor是一个开源的分析容器资源使用率和性能特性的代理工
具，它是因为容器而产生的，因此自然支持Docker容器。在Kubernetes项目中，cAdvisor被集成到Kubernetes代码中，kubelet则通过cAdvisor获取其所在节点及容器上的数据。cAdvisor自动查找其所在Node上的所有容器，自动采集CPU、内存、文件系统和网络使用的统计信息。

容器运行时

kubelet负责本节点上所有Pod的全生命周期管理，其中就包括相关容器的创建和销毁这种基本操作。容器的创建和销毁等操作的代码不属于Kubernetes的代码范畴

kubelet就可以通过CRI插件来实现容器的全生命周期控制了，不同厂家的Container Runtime只需实现对应的CRI插件代码即可，Kubernetes无须重新编译就可以使用更多的容器运行时

CRI接口规范主要定义了两个gRPC接口服务：
ImageService和RuntimeService。其中，ImageService提供了从仓库拉取镜像、查看和移除镜像的功能；RuntimeService则负责实现Pod和容器的生命周期管理，以及与容器的交互（exec/attach/port-forward）。我们知道，Pod由一组应用容器组成，其中包含共有的环境和资源约束，这个环境在CRI里被称为Pod Sandbox。

Container Runtime可以根据自己的内部实现来解释和实现自己的Pod Sandbox，比如对于Hypervisor这种容器运行时引擎，会把PodSandbox具体实现为一个虚拟机。所以，RuntimeService服务接口除了提供了针对Container的相关操作，也提供了针对Pod Sandbox的相关操作以供kubelet调用。在启动Pod之前，kubelet调用RuntimeService.RunPodSandbox来创建Pod环境，这一过程也包括为Pod设置网络资源（分配IP等操作），Pod Sandbox在被激活之后，就可以独立地创建、启动、停止和删除用户业务相关的Container了，当Pod销毁时，kubelet会在停止和删除Pod Sandbox之前首先停止和删除其中的Container。

kube-proxy运行机制解析

为了支持集群的水平扩展和高可用性，Kubernetes抽象出了Service的概念。Service是对一组Pod的抽象，它会根据访问策略（如负载均衡策略）来访问这组Pod。

Kubernetes在创建服务时会为服务分配一个虚拟IP地址，客户端通过访问这个虚拟IP地址来访问服务，服务则负责将请求转发到后端的Pod上。这其实就是一个反向代理，但与普通的反向代理有一些不同：它的IP地址是虚拟，若想从外面访问，则还需要一些技巧；它的部署和启停是由Kubernetes统一自动管理的。

第一代Proxy

kube-proxy进程是一个真实的TCP/UDP代理，类似HA Proxy，负责转发从Service到Pod的访问流量，这被称为userspace（用户空间代理）模式。如图5.17所示，当某个客户端Pod以ClusterIP地址访问某个Service时，这个流量就被Pod所在Node的iptables转发给kube-proxy进程，然后由kube-proxy建立起到后端Pod的TCP/UDP连接，再将请求转发到某个后端Pod上，并在这个过程中实现负载均衡功能。

第二代proxy

从1.2版本开始，Kubernetes将iptables作为kube-proxy的默认模式，Client向Service的请求流量通过iptables的NAT机制直接发送到目标Pod，不经过kube-proxy进程的转发，kube-proxy进程只承担了控制层面的功能，即通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息，并更新Node节点上相应的iptables规则

据Kubernetes的网络模型，一个Node上的Pod与其他Node上的Pod应该能够直接建立双向的TCP/IP通信通道，所以如果直接修改iptables规则，则也可以实现kube-proxy的功能，只不过后者更加高端，因为是全自动模式的。与第一代的userspace模式相比，iptables模式完全工作在内核态，不用再经过用户态的kube-proxy中转，因而性能更强。

第三代Proxy

第二代的iptables模式实现起来虽然简单，性能也提升很多，但存在固有缺陷：在集群中的Service和Pod大量增加以后，每个Node节点上iptables中的规则会急速膨胀，导致网络性能显著下降，在某些极端情况下甚至会出现规则丢失的情况，并且这种故障难以重现与排查。于是Kubernetes从1.8版本开始引入第三代的IPVS（IP Virtual Server）模式。IPVS在Kubernetes 1.11版本中升级为GA稳定版本。

iptables与IPVS虽然都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：iptables是为防火墙设计的；IPVS专门用于高性能负载均衡，并使用更高效的数据结构（哈希表），允许几乎无限的规模扩张，因此被kube-proxy采纳为第三代模式。

与iptables相比，IPVS拥有以下明显优势：

• 为大型集群提供了更好的可扩展性和性能；
• 支持比iptables更复杂的复制均衡算法（最小负载、最少连接、加权等）；
• 支持服务器健康检查和连接重试等功能；
• 可以动态修改ipset的集合，即使iptables的规则正在使用这个集合。

由于IPVS无法提供包过滤、airpin-masquerade tricks（地址伪装）、SNAT等功能，因此在某些场景（如NodePort的实现）下还要与iptables搭配使用。在IPVS模式下，kube-proxy又做了重要的升级，即使用iptables的扩展ipset，而不是直接调用iptables来生成规则链。