Kubernetes核心组件围绕“声明式状态管理”协同工作：控制平面（API Server、etcd、Scheduler、Controller Manager）负责决策与状态维护，工作节点（Kubelet、Container Runtime、Kube-proxy）执行落地，Pod为最小调度单元。

Kubernetes核心组件不是孤立运行的模块，而是围绕“声明式状态管理”协同工作的有机整体。理解它们的关键，在于分清谁做决策、谁执行动作、谁保存事实。

控制平面：集群的决策中枢

控制平面是整个集群的大脑，所有全局性判断和状态维护都发生在这里。它不直接运行业务容器，但决定容器该在哪跑、跑几个、怎么连、出问题了怎么补。

• API Server：唯一入口。所有操作（kubectl、UI、CI/CD）都必须经它校验、鉴权、写入etcd。它是无状态的，可以水平扩容。
• etcd：集群的唯一真相来源。所有资源对象（Pod、Service、Deployment等）的状态快照都持久化在此。它不是数据库替代品，而是强一致性的键值存储，不可被绕过。
• Scheduler：实时匹配器。它监听未调度的Pod，结合节点资源、亲和性、污点容忍等规则，选出最合适的Node，并把绑定结果写回API Server。
• Controller Manager：状态调和者。它包含多个控制器（如ReplicaSet、Node、Endpoint控制器），持续比对etcd中“期望状态”和实际观察到的状态，自动发起修正动作（创建/删除Pod、更新Endpoint等）。

工作节点：容器落地的执行单元

每个工作节点负责承载真实负载，它的组件轻量但关键，全部面向本地执行。

• Kubelet：节点上的“现场管理员”。它定期向API Server上报本机状态（资源、健康、Pod列表），并根据分配给它的PodSpec拉起容器、监控进程、上报事件、执行探针检查。
• Container Runtime：真正运行容器的引擎。Kubernetes本身不绑定Docker，主流选择是containerd或CRI-O。Kubelet通过CRI（容器运行时接口）与之通信，完成镜像拉取、容器启停、日志读取等操作。
• Kube-proxy：网络规则同步器。它监听Service和Endpoint变化，将集群内服务发现与负载均衡逻辑，翻译成节点级的iptables或IPVS规则，确保Pod之间可通过Service名称互通。

Pod：最小调度与生命周期单元

Pod不是组件，却是所有组件协作的落脚点。它是Kubernetes中可被调度、管理、扩缩的最小原子单位。

• 一个Pod可封装一个或多个紧密耦合的容器（如主应用+sidecar日志采集器），共享网络命名空间和存储卷。
• 用户从不直接操作容器，而是定义Pod模板（常通过Deployment、StatefulSet等控制器间接管理）。
• Kubelet负责Pod在本节点的全生命周期——启动、健康检查、重启策略执行、优雅终止。

组件间如何真正联动？以部署一个Nginx为例

当你执行kubectl apply -f nginx-deployment.yaml时，背后是一条清晰的数据流：

• API Server接收请求，校验后存入etcd；
• Controller Manager中的Deployment控制器检测到新资源，创建对应的ReplicaSet；
• ReplicaSet控制器计算副本数差额，生成待调度的Pod对象并写入etcd；
• Scheduler监听到未调度Pod，选定节点后，将“nodeName”字段写回该Pod对象；
• Kubelet在目标节点上发现归属自己的Pod，调用containerd拉取nginx镜像并启动容器；
• Kube-proxy在所有节点上同步Service规则，让集群内其他Pod能通过http://nginx-svc:80访问它。