1.Kubernetes API Server原理解析

Kubernetes API Server的核心功能是提供Kubernetes各类资源对象（如Pod、RC、Service等）的增删改查及Watch等HTTP Rest接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。同时，是集群管理的入口；是资源配额控制的入口；提供完备的集群安全机制。

1.1.Kubernetes API Server概述

Kubernetes API Server通过一个名为kube-apiserver的进程提供服务，该进程运行在master上。默认情况下，kube-apiserver进程在本机的8080端口（对应参数—insecure-port）提供REST服务。同时可以启动HTTPS安全端口（—secure-port=6443）来启动安全机制，加强REST API访问的安全性。
登录Master运行 curl localhost:8080/api 可以获得Kubernetes API的版本信息。
目前最新版本1.21版本似乎没有开启apiserver8080端口。

1.2.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操作。这里解读API Server中资源对象的List-Watch机制。下图以一个完整的Pod调度过程为例，对API Server的List-Watch机制进行说明。

1.3.Kubernetes Proxy API接口

Kubernetes Proxy API的作用是代理REST请求，即Kubernetes API Server把收到的REST请求转发到某个Node的kubelet守护进程的REST端口，由该kubelet进程负责响应。
eg:curl localhost:8080/api/v1/proxy/nodes/<node_name>/pods 查看指定节点所有的Pod信息。
更多使用百度。

1.4.集群功能模块之间的通信

Kubernetes API Server作为集群的核心，负责各功能模块之间的通信。集群内的各个功能模块通过API Server将信息存入etcd，当需要获取和操作这些数据时，则通过API Server提供的REST接口（用GET、LIST或WATCH方法）来实现，从而实现各模块的信息交互。
2019121141.jpg
常见的交互场景是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。

2.Controller Manager原理解析

再Kubernetes集群中，每个Controller都是一个“操作系统”，它们通过API Server提供的（List-Watch）接口实时监控集群中特定资源的状态变化，当发生各种故障导致某资源对象的状态发生变化时，Controller回尝试将其状态调整为期望的状态。比如当某个Node宕机时，Node Controller会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态。Controller Manager时Kubernetes中各种操作系统的管理者，是集群内部的管理控制中心，也是Kubernetes自动化功能的核心。
在Kubenetes集群中与Controller Manager并重的宁一个组件时Kubernetes Scheduler，它的作用是将待调度的Pod（包括通过API Server新创建的Pod及RC为补足副本而创建的Pod等）通过一些复杂的调度流程计算出最佳目标节点，然后绑定在该节点上。

2.1.Replication Controller

该Replication Controller是指Controller Manager里面的副本控制器，不是资源对象RC。
Replication Controller的核心作用是确保在任何时候集群中某个RC关联的Pod副本数量都保持预设值。只有当Pod的重启策略是Always时（RestartPolicy=Always），Replication Controller才会管理该Pod的操作（销毁、重启、创建等）。通常情况下，Pod对象被重新创建后不会消失，唯一例外是当Pod处于succeeded或failed状态时间过长时，该Pod会被系统自动回收，管理该Pod的副本控制器将在其他节点上重新创建、运行该Pod对象。
Replication Controller的职责：
（1）确保在当前集群中有且仅有N个Pod实例，N是在RC中定义的 Pod副本数量。


（2） 通过调整RC的spec.replicas属性值来实现系统扩容或者缩容。
（3） 通过改变RC中的Pod模板（主要是镜像版本）来实现系统的 滚动升级。

2.2.Node Controller

kubelet进程在启动时通过API Server注册自身的节点信息，并定时向API Server汇报状态信息，API Server在接收到这些信息后，会将这些信息更新到etcd中。在etcd中存储的节点信息包括节点健康状态、节点资源、节点名称、节点地址信息、操作系统版本、Docker版本、kubelet版本等。节点健康状态包括“就绪”（true）、“未就绪”（false）、“未知”（unkonw）三种。
Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群中的各个Node的相关控制功能。

2.3.ResourceQuota Controller

资源配额管理。确保指定资源在任何时候不会超量占用系统物理资源。

2.4.Namespace Controller

用户通过API Server可以创建新的Namespace并将其保存到etcd中，Namespace Controller定时通过API Server来读取这些Namespace Controller的信息。如果Namespace被API标识优雅删除，则将该Namespace的状态设置成Terminating并保存到etcd中。同时删除该namespace下的资源对象。

2.5.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对象。
kube-proxy进程获取每个Service的Endpoints，实现了Service的负载均衡功能。
Service Controller属于Kubernetes集群与外部的云平台之间的一个接口控制器。Service Controller监听Service的变化，如果该Service是一个LoadBalancer类型的Service，则Service Controller确保在外部的云平台上该Service对应的LoadBalancer实例被相应地创建、删除及更新路由转发表。

3.Scheduler原理解析

Kubernetes Scheduler的作用是将带调度的Pod按照特定的调度算法和调度策略绑定到集群中某个合适的Node上，并将绑定信息写入etcd中。在整个调度过程中涉及三个对象，分别是待调度列表、可用Node列表，以及调度算法和策略。就是通过调度算法调度为待调度Pod列表中的每一个Pod从Node列表中选择一个最适合的Node。随后，目标节点的kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，然后获取对应的Pod清单，下载Image镜像并启动容器。
Kubernetes Scheduler提供的默认调度流程分为以下两步：
（1）预选调度过程，即遍历所有目标Node，筛选出符合要求的候选节点；
（2）确定最优节点，在第一步的基础上，才有优先策略计算出每个候选节点的积分，积分最高者胜出。

4.kubelet运行机制解析

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

5.kube-proxy运行机制解析

为了支持集群的高水平扩展、高可用性，Kubernetes抽象出了Service的概念。Service是对一组Pod的抽象，它会根据策略（如负载均衡策略）来访问这组Pod。
Kubernetes在创建服务时会为服务分配一个虚拟的IP地址，客户端通过访问这个虚拟的IP地址来访问服务，服务则将请求转发到后端的Pod上。
在Kubernetes集群的每个Node上都会运行一个kube-proxy服务进程，可以把这个进程看作Service的透明代理兼负载均衡器，其核心功能是将某个Service的访问请求转发到后端的多个Pod实例上。