前言
Kubernetes（简称 K8S）是目前业界主流的容器编排引擎，核心能力是实现容器化应用的自动化部署、弹性扩缩容、自愈与生命周期管理。想要真正掌握 K8S，吃透集群架构与核心组件的职责、协作逻辑是必经之路。
本文将从零拆解 K8S 集群的完整架构，清晰划分组件边界，讲透每个组件的核心作用、工作原理与协作流程，无论是入门学习还是面试备考，都能作为体系化的参考资料。
一、K8S 集群整体架构
K8S 采用经典的中心化分布式架构，整体划分为两大核心平面，所有组件协同工作，共同实现集群的声明式控制能力：
- 控制平面（Control Plane）：也叫 Master 节点，是集群的「大脑」，负责集群的全局决策、资源调度、状态管控与 API 暴露，不直接运行业务容器。
- 数据平面（Data Plane）：也叫 Worker/Node 节点，是集群的「手脚」，负责接收控制平面的指令，真正运行业务 Pod（容器组），处理集群网络与流量转发。
核心设计理念：K8S 的核心是声明式 API + 控制循环（调谐 Reconcile）。用户只需要通过 API 提交「期望状态」，集群各个组件会持续监听状态，自动将集群实际状态调谐至与期望状态一致，这也是 K8S 自愈能力的核心来源。
二、控制平面核心组件详解
控制平面是集群的管控核心，生产环境中建议至少 3 节点高可用部署，避免单点故障。其核心组件均运行在 Master 节点上，职责划分清晰，且所有组件仅通过kube-apiserver通信，无直接交互。
1. kube-apiserver：集群唯一入口与 API 网关
kube-apiserver是 K8S 集群的唯一前端入口，也是所有组件通信的唯一枢纽，更是声明式 API 的核心载体。
- 核心职责
- 暴露 K8S RESTful API，处理所有集群操作请求（包括 kubectl 命令、控制台操作、组件间调用）；
- 完成请求的全链路校验：身份认证（Authentication）、权限授权（Authorization）、准入控制（Admission Control）；
- 唯一能与 etcd 集群直接交互的组件，负责集群状态的读写与持久化；
- 基于 watch 机制，向其他组件推送资源状态变更事件，是控制循环的触发核心。
- 关键特性：无状态设计，支持水平扩容，生产环境可多实例部署提升可用性与并发能力。
2. etcd：集群的唯一状态数据库
etcd 是一款高可用的分布式键值（KV）存储数据库，是 K8S 集群唯一的持久化存储组件，相当于集群的「心脏」。
- 核心职责
- 持久化存储集群的所有资源对象数据（Deployment、Pod、Service、ConfigMap 等）与集群状态；
- 基于 Raft 一致性协议，保证集群数据的强一致性与高可用；
- 为 apiserver 提供 watch 能力，支撑集群状态的实时变更推送。
- 关键注意点
- 只有 kube-apiserver 有权限直接读写 etcd，其他任何组件都不能直接操作 etcd；
- 生产环境必须部署 etcd 集群（通常 3/5 节点），并做好定期数据备份，etcd 数据丢失意味着集群状态完全丢失。
3. kube-scheduler：集群的调度器
kube-scheduler是集群的「调度中枢」，核心职责是为新创建的、未绑定节点的 Pod，选择一个最合适的 Node 节点运行。
- 核心工作流程（两步核心调度）
- 过滤阶段（Predicate）：遍历所有 Node 节点，过滤掉不满足 Pod 运行要求的节点（比如资源不足、端口冲突、亲和性 / 反亲和性不匹配、污点容忍度不满足等）；
- 打分阶段（Priority）：对过滤后的合格节点进行优先级打分，综合考虑资源利用率、节点负载、亲和性、数据本地化等维度，选择得分最高的节点；
- 绑定操作：将调度结果写入 apiserver，完成 Pod 与 Node 的绑定，后续由对应节点的 kubelet 执行 Pod 创建。
- 关键特性：支持自定义调度策略、自定义调度器，可满足复杂的业务调度需求。
4. kube-controller-manager：控制器管理器
kube-controller-manager是 K8S「声明式控制」的核心实现，本质是多个独立控制器的集合，每个控制器都是一个独立的控制循环，持续监听对应资源的状态，完成调谐工作。
- 核心工作逻辑：每个控制器持续通过 apiserver 监听资源的「期望状态」与「实际状态」，若两者不一致，自动执行调谐操作，推动实际状态向期望状态对齐。
- 核心内置控制器
- Node 控制器：监控节点状态，节点故障时自动执行故障检测与 Pod 驱逐；
- Deployment/ReplicaSet 控制器：管理无状态应用的副本数，确保 Pod 副本数量与用户声明的一致，实现滚动更新、回滚等能力；
- EndpointSlice 控制器：为 Service 关联后端 Pod，维护服务与 Pod 的网络映射关系；
- ServiceAccount/Token 控制器：管理集群账号与访问令牌，为新命名空间创建默认账号。
- 关键特性：支持控制器的自定义扩展（CRD+Operator），是 K8S 生态扩展的核心能力。
5. cloud-controller-manager：云控制器管理器
cloud-controller-manager（简称 CCM）是 K8S 与底层云基础设施的解耦层，负责对接公有云 / 私有云厂商的 API，将集群与云平台的基础设施能力联动。
- 核心职责：把 K8S 中与云厂商相关的控制逻辑从主集群中剥离，实现云平台适配与集群内核的解耦。
- 核心内置控制器
- 节点控制器：同步云服务器的生命周期，管理节点的创建、删除与状态同步；
- 路由控制器：配置云平台的底层网络路由，实现 Pod 跨节点网络互通；
- 服务控制器：对接云平台的负载均衡服务，为 LoadBalancer 类型的 Service 自动创建公网 / 内网负载均衡实例；
- 卷控制器：对接云平台的块存储服务，自动创建、挂载云存储卷。
- 关键注意点：仅在对接云平台时需要部署，纯本地私有集群（离线部署）无需该组件。
三、数据平面（Node 节点）核心组件详解
Node 节点是集群的工作节点，集群的所有业务容器都运行在 Node 节点上。每个 Node 节点都必须运行以下 3 个核心组件，持续与控制平面通信，执行管控指令，保障节点与 Pod 的正常运行。
1. kubelet：节点的核心代理
kubelet是运行在每个 Node 节点上的「节点代理」，是控制平面在节点上的执行入口，也是节点与 Pod 生命周期管理的核心组件。
- 核心职责
- 持续从 kube-apiserver 监听绑定到当前节点的 Pod 清单，按照声明要求，调用容器运行时创建、启动、停止、销毁容器；
- 执行 Pod 的全生命周期健康检查：存活探针（Liveness Probe）、就绪探针（Readiness Probe）、启动探针（Startup Probe），根据探针结果执行容器重启、流量摘除等操作；
- 持续上报节点的资源状态（CPU、内存、磁盘）、节点健康状态、Pod 运行状态到 kube-apiserver，供调度器与控制器决策；
- 管理节点的容器资源、存储卷挂载、容器网络配置，保障 Pod 的运行环境符合声明要求。
- 关键特性：通过 CRI（容器运行时接口）与容器运行时解耦，不绑定具体的容器 runtime，适配所有符合 CRI 规范的容器运行时。
2. 容器运行时（Container Runtime）
容器运行时是真正负责运行容器的软件，是 Node 节点上容器生命周期的底层执行者，符合 K8S CRI（容器运行时接口）规范。
- 核心职责：负责容器的镜像拉取、容器创建 / 启动 / 停止 / 删除、容器资源隔离与限制、容器日志收集等底层操作。
- 主流合规实现
- containerd：目前 K8S 默认的容器运行时，轻量、稳定、兼容 OCI 标准，是生产环境的首选；
- CRI-O：专为 K8S 设计的轻量级容器运行时，完全兼容 CRI 规范，无冗余功能；
- 注意：K8S 自 1.24 版本起正式废弃 dockershim，Docker 不再作为默认容器运行时，若需使用 Docker 需额外适配 CRI 接口。
3. kube-proxy：节点网络代理
kube-proxy是运行在每个 Node 节点上的网络代理，是 K8S Service 资源的底层实现者，负责集群的服务发现与四层流量负载均衡。
- 核心职责
- 持续从 kube-apiserver 监听 Service 与 EndpointSlice 的变更，在节点上维护对应的网络转发规则；
- 实现 ClusterIP、NodePort、LoadBalancer 等类型 Service 的流量转发，将访问 Service 的流量，按照负载均衡策略转发到对应的后端 Pod；
- 保障集群内部 Pod 与 Service 之间的网络互通，实现跨节点的服务访问。
- 核心转发模式
- iptables 模式：默认模式，基于 Linux 内核 iptables 实现规则转发，稳定性高，适合中小规模集群；
- ipvs 模式：基于 Linux 内核 IPVS 模块实现，性能更高、负载均衡策略更丰富，适合大规模集群（上千节点 / 上万 Service）。
四、集群核心附加组件（Addons）
以下组件并非 K8S 集群的内置核心组件，不属于集群启动的必要条件，但却是生产环境必备的能力补充，也是入门学习必须了解的生态组件。
| 组件名称 | 核心作用 |
|---|---|
| CNI 网络插件 | 实现 K8S 集群 Pod 跨节点网络互通，K8S 本身不实现网络，依赖 CNI 插件，主流实现：Calico、Flannel、Cilium |
| CoreDNS | 集群内部 DNS 服务，为 Pod 和 Service 提供域名解析，是集群服务发现的核心，默认随集群部署 |
| Ingress Controller | 集群七层流量入口网关，实现 HTTP/HTTPS 域名路由、SSL 终结、流量管控，将集群内服务暴露到公网，主流实现：Nginx Ingress、Traefik、APISIX |
| Metrics Server | 集群核心指标采集组件，采集节点与 Pod 的 CPU、内存使用率，为 kubectl top 命令、HPA 弹性扩缩容提供指标支撑 |
| Prometheus+Grafana | 集群监控方案，实现集群组件、节点、业务应用的全链路指标监控、告警与可视化 |
| Loki/ELK Stack | 集群日志收集与分析方案，实现容器日志、组件日志的统一采集、检索与可视化 |
五、核心流程示例：一条 kubectl 命令背后的组件协作
为了让大家更清晰地理解组件间的联动，我们以kubectl create deployment nginx --image=nginx --replicas=3为例，拆解完整的执行流程：
- 用户执行 kubectl 命令，kubectl 对请求进行封装，发送到 kube-apiserver；
- kube-apiserver 完成请求的认证、授权、准入控制，校验通过后，将 Deployment 资源写入 etcd；
- kube-controller-manager 中的 Deployment 控制器监听到 Deployment 资源的创建事件，对比期望状态，创建对应的 ReplicaSet 资源，写入 apiserver 并持久化到 etcd；
- ReplicaSet 控制器监听到 ReplicaSet 创建事件，按照声明的 3 个副本数，创建 3 个 Pod 资源，写入 apiserver 并持久化到 etcd，此时 Pod 处于
Pending状态，未绑定节点；- kube-scheduler 监听到未绑定节点的 Pod，执行过滤 + 打分调度，为每个 Pod 分配最合适的 Node 节点，将调度结果写入 apiserver；
- 对应 Node 节点的 kubelet 监听到绑定到自身节点的 Pod，调用容器运行时 containerd 拉取 nginx 镜像，创建并启动容器；同时执行 Pod 的健康检查；
- kubelet 持续上报 Pod 的运行状态到 apiserver，更新 Pod 状态为
Running；- EndpointSlice 控制器监听到 Pod 的就绪状态，为对应的 Service（若创建）更新后端 Endpoint，kube-proxy 同步更新节点上的网络转发规则，完成服务接入。
六、核心要点
- 核心边界：控制平面负责决策，数据平面负责执行，所有组件的通信唯一枢纽是 kube-apiserver，无跨组件直接通信；
- 数据核心：etcd 是集群唯一的持久化存储，是集群的核心命脉，生产环境必须做好高可用与备份；
- 设计核心：声明式 API + 控制循环是 K8S 的灵魂，所有的自愈、扩缩容、编排能力都基于该设计实现
K8S 集群的架构设计看似复杂，实则职责划分非常清晰：控制平面的组件各司其职，完成集群的全局管控与决策；数据平面的组件稳定执行，保障业务容器的正常运行与网络互通；丰富的生态组件则补齐了生产环境所需的可观测性、网关、安全等能力。掌握了集群架构与组件的核心逻辑，就掌握了 K8S 的底层原理。