k8s_三大类组件介绍

总结

api server：请求入口；
etcd：数据源；
scheduler：决策pod放哪个节点；
controller manager：操作pod
① node controller： 监控
② replicaset controller： 增删
③ deployment controller： 更新

kubelet：开工并监工
kube-proxy：路由器
docker：容器运行时

CoreDNS： 域名解析
网络插件： 网络插件

在Kubernetes（简称k8s）集群中，

有一系列核心组件协同工作，

共同维持集群的正常运行。

---

这些组件可以分为

控制平面组件（集群的“大脑”，负责决策和管理）

和

节点组件（运行在每个服务器上，负责执行具体工作）。

控制平面组件、节点组件；

一、控制平面组件（集群的“指挥中心”）

控制平面通常部署在

集群中的少数专用服务器上（可以是1台或多台，多台用于高可用），

负责集群的全局决策（比如调度、管理、监控等）。

专用服务器；

1 - API Server（“前台接待员”）

职责：所有操作的入口，是k8s中唯一直接和用户/其他组件通信的组件。

作用

1、接收用户的命令（比如kubectl create pod）

2、其他组件的请求

3、验证并处理这些请求

4、然后将结果存入数据库（etcd）

etcd是什么东西呢？

---

打个比方：

API Server就像公司的前台，

所有访客（用户/组件）都必须通过它登记，

它再把信息传给内部（其他组件）。

2 - etcd（“数据库管理员”）

职责

存储集群的所有配置数据。

比如Pod的定义、服务的信息、节点状态等。

---

作用

k8s集群的唯一数据源，

所有组件需要集群信息时，都从这里读取；

所有配置变更也会同步到这里。

---

比如：

你创建了一个Pod，

API Server会把这个Pod的信息存入etcd；

后续调度器需要知道有这个Pod，就会从etcd读取。

3 - Scheduler（“调度员”）

职责

决定哪个Pod、应该放在、哪个服务器（节点）上运行。

作用

当用户创建Pod后，

Scheduler会根据一系列规则

（比如节点的CPU/内存是否足够、是否满足Pod的特殊要求），

从集群中选一个最合适的节点，

然后告诉API Server这个Pod应该放这里。

调度器：决定了pod应该放在哪个节点；

---

类比：就像外卖平台的调度员，根据骑手的位置、负载，把订单分给最合适的骑手。

4 - Controller Manager（“管理员团队”）

职责

运行各种控制器，

确保集群的实际状态和用户期望的状态一致。

作用

控制器是一个个小管家，

比如：

Node Controller：监控节点是否宕机，若宕机则标记并处理相关Pod；

ReplicaSet Controller：确保Pod的数量和用户定义的一致；比如用户要求3个副本，少了就新建，多了就删除）；

Deployment Controller：管理ReplicaSet，支持滚动更新（比如更新应用时，先启动新Pod，再删除旧Pod，避免服务中断）。

管监控、管增删、管更新；

---

简单说：Controller Manager就像小区物业，时刻检查实际情况是否符合规定，不符合就立刻修正。

二、节点组件（集群的“打工人”）

节点组件运行在集群中的每一台服务器（物理机或虚拟机）上，

负责执行控制平面下达的命令，直接运行容器。

1 - Kubelet（“节点监督员”）

职责

确保当前节点上的容器“按规矩运行”。

作用

接收API Server下发的Pod定义

比如这个Pod需要运行3个容器，用XX镜像，

然后调用容器运行时（比如Docker）启动容器；

同时持续监控容器状态

若容器崩溃，会尝试重启；

若Pod被删除，会停止并清理容器。

类比：

就像工厂里的生产线监督员，

确保==机器（容器）按图纸（Pod定义）==工作，

坏了就修，停了就启动。

2 - Kube-proxy（“节点网络代理”）

职责

处理节点的网络规则，实现服务发现和负载均衡。

作用

k8s中的Service（服务）是Pod的稳定访问入口

比如一个服务对应3个Pod，

Kube-proxy会在节点上维护网络规则（比如iptables或ipvs），

确保：

• 外部请求能找到对应的Service（服务发现）；

• 请求能均匀分配到该Service背后的多个Pod上（负载均衡）。

简单说：

Kube-proxy就像节点上的路由器，负责把请求正确转发到目标容器。

3 - 容器运行时（“容器发动机”）

职责

实际运行容器的软件。

作用

接收Kubelet的命令，拉取镜像、创建容器、运行容器等。

常见的容器运行时有Docker、containerd、CRI-O等。

---

类比：

就像汽车的发动机，Kubelet（驾驶员）下令“启动”，发动机就真的让车（容器）跑起来。

三、其他重要组件（“辅助工具”）

除了上述核心组件，

还有一些“配角”但必不可少：

1 - CoreDNS（“集群内部DNS”）

职责

为集群内的Service和Pod提供域名解析服务。

作用

让Pod之间可以通过“域名”（比如my-service.default.svc.cluster.local）互相访问，

而不用记复杂的IP地址。

---

比如Pod A想访问Service B，直接用Service B的域名即可，

CoreDNS会把域名转换成对应的IP。

2 - 网络插件（“集群网络管家”）

职责

实现Pod之间、Pod与外部的网络通信，

确保网络符合k8s的要求（比如每个Pod有独立IP）。

作用

k8s要求每个Pod像一个独立的虚拟机，有自己的IP，

网络插件（如Calico、Flannel）负责搭建这个网络环境，

处理跨节点Pod的通信、网络隔离等。

---

类比：

就像小区的网络布线师傅，确保每家（Pod）都有独立的网线（IP），并且能互相访问。

总结

k8s的组件分工明确：

控制平面（API Server、etcd、Scheduler、Controller Manager）负责“决策和管理”，

节点组件（Kubelet、Kube-proxy、容器运行时）负责“执行和运行”，

再加上CoreDNS（域名解析）、网络插件（网络通信）等辅助组件，

共同构成了一个能自动维护、弹性伸缩的容器集群平台。