Kubernetes核心组件运行机制

Kubernetes基础架构

由上图可知，Kubernetes基础架构由Master和node组成

控制面Master节点主要包含以下组件：

• kube-apiserver：负责对外提供集群各类资源的增删改查及Watch接口，它是Kubernetes集群中各组件数据交互和通信的枢纽。kube-apiserver在设计上可水平扩展，高可用Kubernetes集群中一般多副本部署。当收到一个创建Pod写请求时，它的基本流程是对请求进行认证、限速、授权、准入机制等检查后，写入etcd即可
• kube-scheduler是调度器组件，负责集群Pod的调度。基本原理是通过监听kube-apiserver获取待调度的Pod，然后基于一系列筛选和评优算法，为Pod分配最优的Node节点
• kube-controller-manager包含一系列的控制器组件，比如Deployment、StatefulSet等控制器。控制器的核心思想是监听、比较资源实际状态与期望状态是否一致，若不一致则进行协调工作使其最终一致
• etcd组件，Kubernetes的元数据存储

Node节点主要包含以下组件：

• kubelet，部署在每个节点上的Agent组件，负责Pod的创建运行。基本原理是通过监听APIServer获取分配到其节点上的Pod，然后根据Pod的规格详情，调用运行时组件创建pause和业务容器等。
• kube-proxy，部署在每个节点上的网络代理组件。基本原理是通过监听API-Server获取Service、Endpoint等资源，基于iptables，ipvs等技术实现数据包转发等功能。

iptables的核心功能：通过 API Server 的 Watch 接口实时跟踪 Service 与 Endpoint 的变更信息，并更新对应的 iptables 规则，Client 的请求流量则通过 iptables 的 NAT 机制“直接路由”到目标 Pod。

从基础架构图可以看到，Kube-apiserver是唯一直接与etcd打交道的组件，各组件都通过kube-apiserver实现数据交互，它们极其依赖kube-apiserver提供的资源变化监听机制。而kube-apiserver对外提供的监听机制，也正是etcd Watch特性提供的底层支持。

Kubernetes API Server

        其核心功能是提供Kubernetes各类资源对象（如Pod、RC、Service等）的增、删、改、查及Watch等HTTP Rest接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。此外，还提供以下功能：

• 是集群管理的API入口
• 是资源配额控制的入口
• 提供给了完备的集群安全机制

Kubernetes的设计者如何最大程度保证API Server的性能

1. 在API Server源码中使用协程（Coroutine）+ 队列（Queue）这种轻量级的高性能并发代码，使得单进程的API Server具备了超强的多核处理能力，从而以很快的速度并发处理大量的请求。
2. 普通List接口结合异步Watch接口，不但完美解决了Kubernetes中各种资源对象的高性能同步问题，也极大提升了Kubernetes集群实时响应各种事件的灵敏度。
3. 采用高性能的etcd数据库，解决了数据的可靠性问题，同时也提升了API Server数据访问层的性能，一个三节点的etcd集群在轻负载环境中处理一个请求的事件可以低于1ms，在重负载环境中可以每秒处理超过30000个请求。

API Server架构图：

各层功能如下：

1. API层：主要以REST方式提供各种API接口，除了有Kubernetes资源对象的CRUD和Watch等主要API，还有健康检查、UI、日志、性能指标等运维监控相关的API。Kubernetes1.11之后使用提供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的list watch机制：

如上图所示，kubernetes中的其他组件如Kube-controller-manager、kube-scheduler、kubelet会watch kube-apiserver组件，当有任何Pod被创建时，这些组件都会观察到。而kube-apiserver利用etcd提供的watch接口观察etcd的状态变化。

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

Controller Manager原理解析

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

Controller Manager包括：

• Replication Controller
• Node Controller
• ResourceQuota Controller
• Namespace Controller
• ServiceAccount Controller
• Token Controller
• Service Controller
• Endpoint Controller

Replication Controller：其核心作用是确保在任何时候集群中某个RC关联的Pod副本数量都保持预设值。其主要职责如下：

1. 确保在当前集群中有且仅有N个Pod实例，N是在RC中定义的Pod副本数量
2. 通过调整RC的spec.replicas属性值来实现系统扩容或者缩容
3. 通过改变RC中的Pod模板（主要是镜像模板）来实现滚动升级

总结：重新调度、弹性伸缩、滚动更新。

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

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

p340有张Node Controller核心工作流程图。

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

目前支持三个层次的资源配额管理：

1. 容器级别：可以对CPU和memory进行限制
2. Pod级别：可以对一个Pod内所有容器的可用资源进行限制
3. Namespace级别：为Namespace（多租户）级别的资源限制，比如：Pod数量、Service数量Secret数量等。

NameSpace Controller：用户通过API Server可以创建新的Namespace并将其保存在etcd中，Namespace Controller定时通过API Server读取这些Namespace的信息。

Service Controller与Endpoints Controller：负责生成和维护所有Endpoints对象的控制器，其中Service Controller属于Kubernetes集群与外部的云平台之间的一个接口控制器。Service Controller监听Service的变化，如果该Service是一个LoadBalancer类型的Service（externalLoadbalancers

=true)，则Service Controller确保在外部的云平台上该Service对应的LoadBalancer实例被相应地创建、删除及更新路由转发表。

Scheduler原理：

具体的说，Kubernetes Scheduler将待调度的Pod按照特定的调度算法和调度策略绑定到集群中某个合适的Node上，并将绑定信息写入etcd中。随后，目标节点上的kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，然后获得对应的Pod清单，下载Image镜像并启动容器。以及通过kubelet对Pod的生命周期进行监控。

简言之，通过调度算法调度为带调度Pod列表中的每个Pod从Node列表中选择一个最合适的Node。

kubelet运行机制：

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

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

p350

容器的健康检查：

Pod通过以下两类探针来检查容器的健康状态：

• LivenessProbe探针: 用于判断容器是否健康并返回给kubelet
• ReadinessProbe探针：用于判断容器是否启动完成，且准备接收请求

其中LivenessProbe探针包含以下三种实现：

• ExecAction
• TCPSocketAction
• HTTPGetAction

CAdvisor资源监控：

cAdvisor是一个开源的分析容器资源使用率和性能特性的代理工具，kubelet通过cAdvisor获取其所在节点及容器的数据。cAdvisor自动查找所有在其Node上的容器，自动采集CPU、内存、文件系统和网络使用的统计信息。

Kube-proxy运行机制解析：

为了支持集群的水平扩展、高可用性、Kubernetes抽象出了Service的概念。Service是一组Pod的抽象，它会根据访问策略来访问这组Pod。

在Kubernetes集群的每个Node上都会运行一个kube-proxy服务进程，我们可以把这个进程看作Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。Service的Cluster IP与NodePort等概念是kube-proxy服务通过iptables的NAT转换实现的，kube-proxy在运行过程中动态创建与Service相关的iptables规则，这些规则实现了将访问服务（Cluster IP或NodePort）的请求负载分发到后端Pod的功能。

未完待续... iptables

主要通过操作filter和nat表来实现流量的转发