概述
Kubernetes 核心组件运行机制基于一种高度解耦合、声明式的架构设计，其主要组件包括 Kubernetes API Server、etcd、kube-scheduler、kube-controller-manager、kubelet 和 kube-proxy，各组件协同工作以实现容器集群的高效管理和资源调度。
API Server 其核心功能是提供各种资源的增、删、改、查及Watch，是各个功能模块之间通信的中心枢纽。
- 集群管理的API入口
- 资源配额控制入口
- 集群安全机制
API Server
通过一个名称为kube-apiserver的进程提供服务，该进程运行在Master上。默认情况下，在本机的8080端口。
我们通常可以通过kubectl来与API Server进行交互，他们之间的接口是RESTfull API。
由于API Server是Kubenetes集群数据的唯一入口，因此安全性与高性能就成为API Server设计和实现的两大核心目标。通过HTTPS安全通道与CA签名数字证书强制双向认证的方式，使得API Server的安全性得以保证。为了更细粒度的控制用户或应用对k8s资源对象的访问权限，k8s启用了RBAC访问控制策略。
API Server性能是决定k8s集群整体性能的关键因素，因此k8s的设计者运用以下方式来最大程度的保证API Server的性能
- 大量高性能的底层代码
- 普通
List接口结合异步Watch接口 - 采用高性能数据库
ETCD
API Server 架构
API Server架构从上到下分为一下几层：
- API层：主要以
REST方式提供各种API接口，除了Kubernetes资源对象的CRUD和Watch等主要API,还有健康检查、UI、日志、性能指标等运维监控相关的API。 - 访问控制层：当客户端访问API接口时，访问控制层负责对用户身份鉴权，验明用户身份，核对权限。
- 注册表层：k8s把所有资源对象都保存在注册表中，针对注册表中的各种资源对象都定义了：资源对象的类型、如何创建资源对象、如何转换资源的不同版本等。
etcd数据库：持久化存储k8s资源对象的kv数据库。etcd的watch的API接口对于API Server来说至关重要，因为通过这个接口，API Server创新性的设计了List-Watch这种高性能的资源对象实时同步机制，使得k8s可以管理超大规模的集群，及时响应和快速处理集群中的各种事件。
如下是一个完整Pod调度过程，对API Server的List-Watch机制进行说明
- 借助
etcd的watchapi接口，API Server可以监听ETCD上发生的数据库操作事件，在这些事件发生后，ETCD会及时通知API Server。 - 为了让k8s的其他组件在不访问
ETCD数据库情况下，也能及时获取资源对象的变化。API Server模仿ETCD提供了自己的Watch接口。 - k8s的
List-Watch用于实现数据同步的代码逻辑。客户端首先调用API Server的List接口获取相关资源对象的全量数据并将其缓存到内存中，然后启用对应资源对象的Watch协程，在接收到Watch事件后，在根据事件类型（新增，修改，删除）对内存中的全量资源对象列表做出响应的同步修改，从实现上来看，这是一种全量结合增量的高性能数据同步方式
Proxy API 接口
k8s的API Server最主要的REST接口是资源对象的增、删、改、查接口，除此之外还提供了代理接口，这类接口的作用是代理REST请求，即API Server将收到的请求转发到某个Node上的kubelet守护进程的Rest接口，该kubelet负责响应。
bash
# 列出指定节点内所有Pod的信息
/api/v1/nodes/{name}/proxy/pods
# 列出指定节点内物理资源的统计信息
/api/v1/nodes/{name}/proxy/stats
# 列出指定节点的概要信息
/api/v1/nodes/{name}/proxy/spec需要说明的是：这里获取的Pod信息数据来自Node而非ETCD数据库
K8s Proxy API里关于Pod的相关接口，通过这些接口，我看可以访问Pod里某个容器提供的服务
bash
# 访问Pod
/api/v1/namespaces/{namespace}/pods/{name}/proxy
# 访问Pod服务的URL路径
/api/v1/namespaces/{namespace}/pods/{name}/proxy/{path:*}集群功能模块之间通信
k8s的API Server作为集群的核心，负责集群各功能模块之间的通信。集群内的各个功能模块通过 API Server将信息存入ETCD，当需要获取和操作这些数据时，则通过API Server提供的REST接口来实现，从而实现各个模块之间的信息交互。
常见的一个交互场景是kubelet进程与API Server的交互。每个node上的kubelet每隔一个时间周期，就会调用一次API Server的REST接口报告自己的状态，API Server在接收到这些信息后，将这些信息保存到ETCD中。此外kubelet也通过API Server的Watch接口监听Pod信息，如果监听到新的Pod的副本被调用到本节点，则执行Pod对应的容器创建和启动逻辑，删除和修改同理。
另一个场景是kube-controller-manager进程与API Server的交互。kube-controller-manager中的Node Controller模块通过API Server提供的Watch接口实时监控node的信息并做相应处理。
调度（Scheduler）通过API Server的Watch接口监听到新的Pod副本信息后，会检索所有符合该Pod要求的Node列表，开始执行Pod调度逻辑，在调度成功后将Pod帮到到目标节点上。
结语
总结 Kubernetes 核心组件运行机制的原理解析，Kubernetes 作为一款先进的容器编排系统，其核心组件通过紧密协作实现了自动化部署、扩展和管理容器化应用的目标。以下是对主要组件运行机制的关键要点总结：
Kubernetes API Server
- 作为集群的中央管控点，
API Server提供了RESTful API接口，处理对集群状态的增删改查操作。 - 所有资源对象（如 Pod、Deployment、Service 等）的管理和控制指令均通过
API Server实现。 API Server连接etcd存储集群的状态数据，并通过Watch机制实时同步状态变更给其他组件。
etcd
- 作为高可用键值存储系统，
etcd存储了Kubernetes集群的所有配置数据和状态信息。 - 其
watch功能使得其他组件能够实时获取数据变更通知，确保集群状态一致性。
kubelet：
- 在每个
Node上运行，kubelet是Master和Worker节点之间的桥梁。 kubelet通过与API Server交互获取Pod的定义，并确保Pod中容器在本地节点按照要求正确创建、运行和维护。
kube-proxy：
- 每个
Node上运行的网络代理服务，实现Kubernetes Service的负载均衡和服务发现功能。 - 它通过监听
API Server中Service对象的变化，动态更新网络规则，确保跨多个Pod的网络流量按需分发。
Controller Manager：
- 包含多个控制器，如
Replication Controller、Endpoint Controller等，它们负责监控集群实际状态并调整至期望状态。 - 控制器通过循环检查与实际状态的差异，并采取相应动作使集群达到一致状态。
Scheduler：
- 负责决定新创建的
Pod应该调度到哪个Node上运行，考虑的因素包括资源需求、亲和性/反亲和性策略等。 CoreDNS 或者之前的 kube-dns： - 提供了集群内部的服务发现能力，使得
Pod能够通过服务名访问集群内其他服务。
综上所述，Kubernetes 的核心组件协同运作，共同构建了一个强大且灵活的分布式系统，它不仅保证了容器化的应用程序具有高可用性、弹性伸缩性和自我修复能力，还极大地简化了大规模分布式系统的管理和运维工作。通过深入了解这些组件的运行机制和原理，用户可以更好地设计和优化在 Kubernetes 上运行的应用程序架构。