当前位置：首页 > news >正文

从“大脑”到“肌肉”：一张图搞懂K8s集群组件架构

news 2026/7/18 2:50:16

本文专为初学者设计，用最通俗的语言拆解Kubernetes集群的各个组件，让你一次性搞懂它们各自是干什么的。

如果把一个K8s集群比作一家大型物流公司：

K8s集群由控制平面和工作节点两大部分组成。控制平面管理集群的整体状态，工作节点则承载实际运行的容器化应用。

下面我们逐一拆解每个组件。

控制平面负责做出集群的全局决策（比如把Pod调度到哪个节点），以及检测和响应集群事件（比如某个Pod挂了需要重新拉起）。它由四个核心组件组成：

API Server是Kubernetes的核心组件，它公开了Kubernetes API，是整个控制平面的前端入口。

所有与集群的交互——无论是你用kubectl敲的命令、其他组件的内部通信，还是外部系统的调用——都必须经过API Server。它负责认证、授权和校验每一个请求。

一句话总结：API Server是集群的“唯一大门”，所有人都得从这里进出。

etcd是一个一致且高可用的键值存储，用作Kubernetes所有集群数据的后台数据库。

集群的每一个状态——有哪些节点、跑了哪些Pod、配置了什么Service——全部保存在etcd里。API Server是唯一与etcd直接交互的组件。

一句话总结：etcd是集群的“记忆中心”，所有信息都记在这里。

Scheduler负责监视新创建的、尚未分配节点的Pod，并为其选择一个最合适的节点来运行。

调度决策会综合考虑资源需求、硬件/软件策略约束、亲和性规范等多种因素。它不是随便乱选，而是“精打细算”地安排。

一句话总结：Scheduler是“调度员”，决定每个Pod去哪台机器上干活。

Controller Manager运行着各种各样的控制器，负责实现Kubernetes API的各种行为。

每个控制器都是一个独立的过程，持续监控系统当前状态，一旦发现与期望状态不一致，就自动执行调整。比如：ReplicaSet控制器确保指定数量的Pod始终在运行；Deployment控制器管理滚动更新和回滚。

一句话总结：Controller Manager是“自动化运维团队”，确保集群始终按你的期望运行。

每个工作节点上都运行着三个核心组件，它们共同负责让容器真正跑起来。

Kubelet是运行在每个工作节点上的主要代理，它负责与API Server通信，确保节点上的容器按照PodSpec的定义正常运行。

Kubelet管理Pod的整个生命周期——创建、运行、健康检查、销毁——并定期向API Server报告节点和Pod的状态。

一句话总结：Kubelet是节点上的“监工”，负责管好本节点上的所有Pod。

Kube-proxy负责维护节点上的网络规则，实现Service的负载均衡和服务发现功能。

简单说，当你要访问某个Service时，kube-proxy帮你把请求正确地转发到后端的某个Pod上。

一句话总结：Kube-proxy是“网络交警”，保证流量走对路。

容器运行时是真正负责运行容器的软件，比如Docker、containerd或CRI-O。

Kubernetes通过容器运行时接口（CRI）与不同的容器运行时进行交互，这使得K8s可以灵活地支持多种运行时。

一句话总结：容器运行时是“一线搬运工”，真正把容器拉起来跑。

假设你执行kubectl create deployment nginx --image=nginx：

💡关键点：所有组件都只与API Server通信，彼此之间不直接打交道。这种设计让各组件松耦合，便于独立升级和扩展。