Kubernetes 核心架构与组件总览

摘要：本文面向生产 SRE 与架构师，建立 Kubernetes 集群的组件心智模型——控制面如何做全局决策、节点组件如何运行业务、所有组件为何都只通过 kube-apiserver 通信。覆盖版本：Kubernetes v1.28+。

适用版本与前提

Kubernetes：v1.28+（文中涉及的高可用、leader election、node lease 等机制在各版本通用，具体默认值以目标版本为准）
前提：已具备集群访问权限，理解 Pod / Node / Service 基本概念
参考文档：kubernetes.io/docs/concepts/architecture/

背景与问题

Kubernetes 要解决的核心问题是：在一组不稳定的机器上稳定地运行一组有依赖关系的容器化应用。为此它把集群拆成两半：

Control Plane（控制面）：做全局决策（调度、自愈、扩缩容、状态存储），是集群的"大脑"。
Node（工作节点）：实际运行业务容器的机器，是集群的"手脚"。

关键设计原则之一：所有组件都是 kube-apiserver 的客户端。控制面内部、节点与控制面之间，没有组件间直连——一切都通过 API Server 这个唯一入口读写状态。这个约束让 Kubernetes 具备了"可组合、可扩展、可替换"的架构弹性。

核心组件

控制面组件

组件	职责	是否必须
kube-apiserver	暴露并校验 Kubernetes REST API，是集群状态唯一读写入口	是
etcd	一致、高可用的键值存储，保存全部集群状态	是
kube-scheduler	监听未绑定节点的 Pod，按资源/亲和/拓扑等约束选节点	是
kube-controller-manager	运行一组控制器（Node、Job、EndpointSlice、ServiceAccount 等）	是
cloud-controller-manager	把云厂商能力（负载均衡、路由、节点生命周期）从集群逻辑中解耦	否（自建集群无）

kube-apiserver 被设计为可水平扩展：可以运行多个实例，前面挂负载均衡器分流。而 etcd 是 leader-based 的，只有一个 leader 对外写入，其余 follower 异步复制——这是整个集群的"单点写入瓶颈"所在，也是生产调优的重点。

kube-scheduler 与 kube-controller-manager 自身通过 leader election（基于 etcd 的 Lease）保证同一时刻只有一个实例真正干活，其余 standby，避免脑裂。

节点组件

组件	职责
kubelet	节点上的"agent"，保证 PodSpec 描述的容器在节点上运行且健康
kube-proxy	维护节点网络规则，实现 Service 的 VIP 转发（部分 CNI 自实现可省）
Container Runtime	真正负责容器生命周期的软件（containerd / CRI-O 等，实现 CRI）

心智模型

记住一句话：kubelet 不管理不是 Kubernetes 创建的容器。它只认通过 API Server 下发的 PodSpec（以及静态 Pod 清单）。这一点在排查"为什么这个 docker 容器没被 K8s 看到"类问题时至关重要。

架构总览图

通信模型与数据流

一次"创建 Pod"的完整链路能串起所有组件：

用户/控制器向 kube-apiserver 提交 Pod 对象（写入 etcd）。
kube-scheduler 通过 watch 发现一个 nodeName 为空的 Pod，计算最优节点并回填。
目标节点 kubelet 通过 watch 发现"调度给我"的 Pod，调用 Container Runtime（CRI） 拉镜像、起容器。
kube-proxy 感知到 Service/EndpointSlice 变化，更新本机 iptables/IPVS 规则。
各组件持续向 API Server 汇报心跳与状态；kube-controller-manager 的各类控制器据此做自愈。

注意：kubelet、scheduler、controller-manager 都不是"被 API Server 推送"，而是主动 watch API Server。这种"声明式 + 无限调和（reconcile）"的模型，是 Kubernetes 自愈能力的来源。

生产实践：控制面如何部署

控制面组件的部署形态有多种（参考 kubernetes.io/docs/concepts/architecture/ 的 "Architecture variations"）：

传统部署：控制面直接跑在专用机器/VM 上，通常为 systemd 托管。
Static Pod：控制面组件作为 kubelet 管理的静态 Pod 运行——kubeadm 默认采用此方式。
Self-hosted：控制面作为集群内的 Deployment/StatefulSet 运行。
托管 K8s：云厂商抽象掉控制面，用户无感（但仍要理解其边界，见下）。

生产注意

控制面组件不要和用户容器混部在同一组机器上（除非是单节点开发集群）。生产环境应为控制面提供独立机器，并确保 etcd 跑在专属、低延迟、有 IOPS 保障的磁盘上。etcd 对磁盘 I/O 与网络抖动极敏感，资源饥饿会触发心跳超时，导致 leader 重新选举、集群短暂不可写。

适用边界与常见失败模式

控制面不是"无状态即可无限扩展"：etcd 写入是单点。扩 kube-apiserver 只能提升读与校验吞吐，不能突破 etcd 写入瓶颈。
网络分区下的脑裂：etcd 依赖奇数成员 + quorum。3 成员容忍 1 个失效，5 成员容忍 2 个。少于 quorum 时集群只读不写。
kube-apiserver 不可用：所有 watch 中断，已运行 Pod 不受影响，但新调度、扩缩容、自愈全部停摆。
kubelet 与 API Server 失联：节点被标记为 Unknown，默认 5 分钟后触发对该节点 Pod 的 API 驱逐（见 kubelet 一文）。

回滚与清理

控制面升级/变更需谨慎，遵循"先备份 etcd，再灰度，后全量"：

生产危险

以下命令会操作 etcd 与生产控制面，执行前必须备份 etcd 快照并确认上下文。误操作可能导致集群状态丢失。

bash

# 1) 变更前先备份 etcd（在 etcd 节点或能访问 etcd 的机器上）
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-$(date +%F).db

# 2) 回滚静态 Pod 控制面：把 Manifest 目录中的 yaml 还原到上一版本
#    kubeadm 集群控制面 Manifest 默认在 /etc/kubernetes/manifests/
ls /etc/kubernetes/manifests/

安全与合规

etcd 等于集群 root：能访问 etcd 就等同于拥有集群全部权限。只允许 API Server 用 TLS 证书访问，必要时叠加防火墙规则。
kube-apiserver 是攻击面集中点：必须开启 RBAC（--authorization-mode=RBAC）、关闭匿名写、启用审计日志。托管集群同样要管好自己的 RBAC 与鉴权。
API Server 与节点间通信全程 mTLS：kubelet ↔ apiserver、etcd peer 间都应加密。

性能、容量与成本

控制面机器规格取决于集群规模（节点数、对象数、API QPS）。对象量越大、控制器越活跃，API Server 与 etcd 压力越高。
多副本 kube-apiserver 能分摊读压力，但 etcd 写入吞吐与磁盘 I/O 是硬上限。大集群应优先考虑分片/多集群而非无限加大单集群。
成本上：控制面三节点冗余有固定开销；托管 K8s 通常按控制面规格计费，自建则需独立预留机器。

可观测性

建议至少观测以下指标判断控制面健康：

etcd：etcd_server_leader_changes_seen_total（leader 频繁切换=异常）、etcd_disk_wal_fsync_duration_seconds（写盘延迟）、etcd_mvcc_db_total_size_in_bytes。
kube-apiserver：请求延迟分位、inflight 请求数、关联 etcd 读延迟。
节点：kubelet 与 API Server 的心跳/lease 是否正常、NodeReady 状态。

常见坑

把用户负载调度到控制面节点：未加 node-role.kubernetes.io/control-plane: NoSchedule 污点时，业务 Pod 可能被调度上去挤占资源。现代 kubeadm 默认打此污点。
etcd 与其他高 IO 负载混部：导致 fsync 延迟飙升，连锁引发集群不稳定。
误以为组件直连：排查问题时别忘了"一切都走 API Server"，瓶颈往往在被忽略的 API Server 或 etcd。

替代方案与权衡

托管控制面 vs 自建：托管省运维但失去部分控制力（如无法自定义 API Server feature gate、无法直连 etcd）。自建灵活但需自己负责备份、升级、容量。
k3s / microk8s 等轻量发行版：把控制面组件打包进单进程，适合边缘/小规模，但生产大规模仍以标准组件模型为主流。

FAQ

Q：kube-proxy 是不是必须？ A：不是。若所用 CNI 自行实现了 Service 转发（如 Cilium 的 eBPF 模式），节点可不运行 kube-proxy。但传统 iptables/IPVS 模式依赖它。

Q：为什么 scheduler/controller-manager 也要多副本？ A：它们通过 leader election 选主，多副本只为 HA 冗余；同一时刻只有一个 active 实例做决策，避免重复调度/重复 reconcile。

参考资料

Kubernetes Components - Kubernetes 官方文档，访问日期：2026-10-08。
Cluster Architecture - Kubernetes 官方文档，访问日期：2026-10-08。
Nodes - Kubernetes 官方文档，访问日期：2026-10-08。

Kubernetes 核心架构与组件总览 ​

适用版本与前提 ​

背景与问题 ​

核心组件 ​

控制面组件 ​

节点组件 ​

架构总览图 ​

通信模型与数据流 ​

生产实践：控制面如何部署 ​

适用边界与常见失败模式 ​

回滚与清理 ​

安全与合规 ​

性能、容量与成本 ​

可观测性 ​

常见坑 ​

替代方案与权衡 ​

FAQ ​

参考资料 ​