Kubernetes 集群架构概述

摘要：本文从全局视角介绍 Kubernetes 的整体架构设计，详解控制平面与数据平面的组件组成、职责划分及其交互流程。

一、整体架构

Kubernetes 采用典型的 控制平面（Control Plane）+ 数据平面（Data Plane） 架构。控制平面负责集群的全局状态管理和决策调度，数据平面由工作节点组成，负责实际运行容器工作负载。
Data Plane 数据平面
Control Plane 控制平面
Worker Node 3
Worker Node 2
Worker Node 1
REST API
用户 kubectl / API Client
kube-apiserver
etcd
kube-scheduler
kube-controller-manager
kubelet
kubelet
kubelet
kube-proxy
Container Runtime
Pod
Pod
kube-proxy
Container Runtime
Pod
Pod
kube-proxy
Container Runtime
Pod
Pod

上图是 Kubernetes 集群的整体架构。控制平面运行在 Master 节点上，通过 API Server 对外提供统一接口；数据平面由多个 Worker 节点组成，每个节点上的 kubelet 负责管理本地 Pod。所有组件之间的通信都通过 API Server 中转，这是 K8s 架构的核心设计原则。

二、控制平面（Control Plane）

控制平面负责集群的全局决策：接收用户请求、存储集群状态、调度 Pod、维护期望状态。通常部署在专用的 Master 节点上，生产环境建议至少 3 个节点以实现高可用。

2.1 核心组件

控制平面
读写
Watch 未调度 Pod

Bind 操作
Watch 资源变化

更新资源状态
kube-apiserver

RESTful API 网关

认证/授权/准入控制
etcd

分布式 KV 存储

集群状态唯一持久化层
kube-scheduler

调度器

为未绑定节点的 Pod 选择最佳节点
kube-controller-manager

控制器管理器

运行多个控制循环维护期望状态

上图展示了控制平面四个核心组件之间的交互关系。Scheduler 和 Controller Manager 都通过 Watch 机制监听 API Server 上的资源变化并做出响应。以下是每个组件的职责说明：

组件	核心职责	技术特性
kube-apiserver	集群的唯一通信入口，提供 RESTful API，执行认证/授权/准入控制	无状态，支持水平扩展，所有组件仅与它通信
etcd	存储集群全部状态数据的分布式键值数据库	Raft 共识算法，仅 API Server 可直接访问
kube-scheduler	为新创建的、尚未绑定节点的 Pod 选择最佳运行节点	两阶段调度：过滤（Filtering）+ 打分（Scoring）
kube-controller-manager	运行多个内置控制器（Deployment、ReplicaSet、Node 等），通过控制循环将实际状态收敛到期望状态	单进程多控制器，Leader 选举保证高可用

2.2 API Server 的中心化通信设计

K8s 架构的一个核心原则是：所有组件仅通过 API Server 进行通信，组件之间不直接交互。
kubectl
kube-apiserver
kube-scheduler
kube-controller-manager
kubelet - Node 1
kubelet - Node 2
kube-proxy
etcd

上图展示了 API Server 作为通信中心的架构。这种设计有以下好处：

安全性：etcd 不直接暴露，减少攻击面；所有请求经过统一的认证/授权链路
解耦：各组件仅依赖 API Server 的接口约定，可独立升级和替换
可审计：所有对集群状态的变更都经过 API Server，便于审计日志记录
一致性：etcd 的读写由 API Server 统一管理，避免并发冲突

三、数据平面（Data Plane）

数据平面由所有 Worker 节点组成，负责实际运行用户的容器工作负载。每个 Worker 节点上运行三个核心组件：
Worker 节点
kubelet

节点代理

管理 Pod 生命周期

执行健康检查探针

向 API Server 汇报节点和 Pod 状态
Pod A / Pod B / Pod C ...
Container Runtime

容器运行时

通过 CRI 接口拉取镜像

创建/启动/停止容器
kube-proxy

网络代理

维护节点上的网络规则

实现 Service 的负载均衡转发

上图展示了 Worker 节点的内部组件结构。kubelet 作为节点代理管理 Pod 生命周期，kube-proxy 负责网络转发规则，Container Runtime 通过 CRI 接口执行实际的容器操作。

组件	核心职责	技术特性
kubelet	管理本节点上 Pod 的生命周期；执行 liveness/readiness/startup 探针；汇报节点状态	通过 Watch 机制监听分配到本节点的 Pod 变更
kube-proxy	维护节点上的网络转发规则，将对 Service ClusterIP 的访问转发到后端 Pod	支持 iptables、IPVS、nftables 三种模式
Container Runtime	通过 CRI（Container Runtime Interface）拉取镜像、创建和管理容器	主流实现为 containerd 和 CRI-O

四、组件协作流程

以用户创建一个 Deployment 为例，追踪请求在各组件之间的完整流转过程：
kubelet kube-scheduler controller-manager etcd kube-apiserver kubelet kube-scheduler controller-manager etcd kube-apiserver 用户 1. kubectl apply -f deployment.yaml 认证 → 授权 → 准入控制 2. 持久化 Deployment 对象 3. Watch 通知：新 Deployment 4. Deployment Controller 创建 ReplicaSet 持久化 ReplicaSet 5. ReplicaSet Controller 创建 Pod（nodeName 为空）持久化 Pod（状态 Pending） 6. Watch 通知：存在未调度 Pod 7. 过滤 + 打分，选择最佳节点 8. Bind Pod 到目标节点更新 Pod 的 nodeName 字段 9. Watch 通知：有 Pod 绑定到本节点 10. 调用 CRI 拉取镜像、创建容器 11. 汇报 Pod 状态：Running 更新 Pod 状态用户

上图详细展示了从用户提交 Deployment 到 Pod 在节点上运行的完整链路。整个过程是事件驱动的：各组件通过 Watch API Server 上的资源变化来触发自身逻辑，而不是定期轮询。这种设计确保了系统的高响应性和低资源开销。

各步骤说明：

用户通过 kubectl 向 API Server 提交 Deployment 定义
API Server 经过认证、授权、准入控制后，将 Deployment 对象持久化到 etcd
Controller Manager 中的 Deployment Controller 通过 Watch 检测到新 Deployment
Deployment Controller 创建对应的 ReplicaSet 对象
ReplicaSet Controller 根据 replicas 字段创建指定数量的 Pod 对象（此时 Pod 的 nodeName 为空）
Scheduler 通过 Watch 检测到存在未绑定节点的 Pod
Scheduler 执行过滤（排除不满足约束条件的节点）和打分（选择最优节点）
Scheduler 将选定节点写入 Pod 的 nodeName 字段
目标节点上的 kubelet 通过 Watch 检测到有新 Pod 绑定到本节点
kubelet 调用 Container Runtime 拉取镜像并启动容器
kubelet 将 Pod 状态更新为 Running

五、集群规模与高可用

5.1 支持的集群规模

Kubernetes 官方测试数据（SLO 目标：API 调用 99th 延迟 < 1s）：

指标	上限
节点数量	5,000
Pod 总数	150,000
容器总数	300,000
每节点 Pod 数	110

实际可支持的规模取决于硬件配置、网络带宽和工作负载特征。

5.2 高可用架构

生产环境必须避免控制平面的单点故障。标准的高可用部署方案如下：
Master 3
Master 2
Master 1
Raft
Raft
Raft
Load Balancer
kube-apiserver
scheduler - Leader
controller-manager - Leader
etcd
kube-apiserver
scheduler - Standby
controller-manager - Standby
etcd
kube-apiserver
scheduler - Standby
controller-manager - Standby
etcd
Worker Nodes ...

上图展示了 3 Master 节点的高可用部署架构。负载均衡器将客户端请求分发到多个 API Server 实例；etcd 通过 Raft 协议保证数据一致性。各组件的高可用策略如下：

组件	高可用策略
kube-apiserver	多实例同时活跃（Active-Active），前置负载均衡
kube-scheduler	多实例 Leader 选举（Active-Standby），仅 Leader 执行调度
kube-controller-manager	多实例 Leader 选举（Active-Standby），仅 Leader 运行控制循环
etcd	奇数节点集群（推荐 3 或 5），Raft 共识保证数据一致性

etcd 使用奇数节点的原因：Raft 协议要求多数节点（quorum）同意才能提交写入。3 节点集群的 quorum 为 2，可容忍 1 个节点故障；5 节点集群的 quorum 为 3，可容忍 2 个节点故障。偶数节点不会提升容错能力但增加了成本。

六、K8s 资源对象概览

Kubernetes 通过各种**资源对象（Resource Object）**来抽象和管理集群中的工作负载、网络、存储和安全策略。以下是主要资源对象的分类：
配置与存储
服务与网络
工作负载 Workloads
挂载/注入
挂载/注入
挂载
集群管理
Namespace
Role / ClusterRole / Binding
ServiceAccount
Deployment
ReplicaSet
Pod
StatefulSet
DaemonSet
Job / CronJob
Service
Ingress
NetworkPolicy
ConfigMap
Secret
PV / PVC / StorageClass

上图展示了 K8s 主要资源对象的分类和关联关系。工作负载类资源最终都管理 Pod；Service 和 Ingress 提供网络访问入口；ConfigMap/Secret 为 Pod 提供配置数据；PV/PVC 提供持久化存储。后续文章将逐一详解每类资源。

七、验证集群架构

可以通过以下 kubectl 命令查看集群架构信息：

bash 复制代码

# 查看集群基本信息（API Server 和 CoreDNS 地址）
kubectl cluster-info

# 查看所有节点及其角色、版本、IP
kubectl get nodes -o wide

# 查看控制平面组件运行状态
kubectl get pods -n kube-system

# 输出示例：
# NAME                                   READY   STATUS    RESTARTS
# coredns-xxxx-yyyy                      1/1     Running   0
# etcd-master-0                          1/1     Running   0
# kube-apiserver-master-0                1/1     Running   0
# kube-controller-manager-master-0       1/1     Running   0
# kube-proxy-xxxxx                       1/1     Running   0
# kube-scheduler-master-0                1/1     Running   0

# 查看组件健康状态（K8s 1.19+ 部分版本已废弃此 API）
kubectl get componentstatuses

八、总结

核心概念	说明
控制平面	由 API Server、etcd、Scheduler、Controller Manager 组成，负责全局决策和状态管理
数据平面	由 Worker 节点组成，每个节点运行 kubelet、kube-proxy 和 Container Runtime
通信模型	所有组件仅通过 API Server 通信，API Server 是唯一的 etcd 访问入口
事件驱动	组件通过 Watch 机制实时监听资源变化并响应，而非轮询
高可用	控制平面多副本部署，API Server Active-Active，Scheduler/CM Leader 选举，etcd Raft 共识