Kubernetes 核心架构

作者：JiangChong | 撰写时间：2026年07月

✅ 学完本文你将能够： ✅ 描述控制平面和工作节点的核心组件及其职责 ✅ 理解 API Server、etcd、Scheduler 和 Controller Manager 如何协同工作 ✅ 区分声明式 API 和控制器模式的设计理念 ✅ 了解 CRD 和 Operator 如何扩展 K8s 的能力边界

前置知识：本文假设你了解容器（Container）的基本概念。如果不熟悉，简单理解：容器是一个轻量级的、包含应用程序及其依赖的隔离运行环境。Kubernetes 解决的问题是：当你有几十上百个容器跑在多台机器上时，如何自动部署、调度、扩缩、恢复？

无需 K8s 前置知识，这是本系列的第一篇。

1. 概述

Kubernetes（K8s）是一个用于自动部署、扩缩和管理容器化应用程序的开源平台。在没有 K8s 的时代，运维工程师通过 SSH 登录服务器，手工启动容器。当容器数量从 3 个增长到 300 个、分布在 30 台机器上时，这种方式完全不可持续。Kubernetes 把一群机器变成一台"超级计算机"，你只需要告诉它"我要 3 个 nginx 实例"，剩下的它自动完成。理解其核心架构是掌握 K8s 的第一步。K8s 集群由控制平面（Control Plane） 和工作节点（Worker Node） 两大部分组成，它们通过声明式 API 和控制器模式协同工作。声明式 API 的意思是：你告诉 K8s "我想要什么状态"（比如运行 3 个 nginx 副本），K8s 自己想办法达到并维持这个状态，你不需要告诉它每一步怎么做。

┌───────────────────────────────────────────┐
│           控制平面 (Control Plane)         │
│  ┌────────┐ ┌─────────┐ ┌──────────┐      │
│  │API     │ │Scheduler│ │Controller│      │
│  │Server  │ │         │ │Manager   │      │
│  └───┬────┘ └─────────┘ └──────────┘      │
│      │                                    │
│  ┌───▼────┐ ┌───────────┐                 │
│  │  etcd  │ │Cloud Ctl  │                 │
│  └────────┘ │Manager(*) │                 │
│             └───────────┘                 │
└──────────────────┬────────────────────────┘
                   │
┌──────────────────▼────────────────────────┐
│        工作节点 (Worker Node)              │
│  ┌────────┐ ┌──────────┐ ┌────────┐       │
│  │kubelet │ │kube-proxy│ │Runtime │       │
│  │        │ │ (可选)    │ │        │       │
│  └────────┘ └──────────┘ └────────┘       │
│  ┌──────────────────────────────────┐     │
│  │        Pod (容器组)               │     │
│  └──────────────────────────────────┘     │
└───────────────────────────────────────────┘

生活化比喻： 把控制平面想象成公司的"管理层"——做决策、发指令；工作节点是"执行层"——实际干活的服务器。API Server 是公司前台（所有请求都通过它），etcd 是档案室（存所有记录），Scheduler 是人事部（分配工作），Controller Manager 是各部门经理（盯着实际状态与期望是否一致）。

---

2. 控制平面组件

2.1 kube-apiserver — 前端大门

API Server 是整个 K8s 的入口，所有组件（kubectl、Scheduler、Controller Manager、kubelet）都通过它通信。它的核心职责包括：

• RESTful API：暴露 CRUD 操作，所有资源（Pod、Service、Deployment 等）均通过 API 进行管理
• 认证（Authentication）：支持多种认证方式 — X509 客户端证书、ServiceAccount Token、OpenID Connect、Webhook 等
• 授权（Authorization）：通过 RBAC、ABAC 或 Webhook 判断请求是否有权限
• 准入控制（Admission Control）：在资源持久化之前执行一系列插件，如 MutatingAdmissionWebhook（修改请求）、ValidatingAdmissionWebhook（校验请求）、ResourceQuota（资源配额检查）、PodSecurity（安全策略）

API Server 是唯一与 etcd 直接交互的组件。它缓存了大部分数据以降低 etcd 的读取压力，只有 List/Watch 请求会透传至 etcd。

API Server 设计上支持水平扩缩 — 可通过部署多个实例并前置负载均衡器来提升集群容量和可用性，这也是多 Master 高可用部署的基础。

2.2 etcd — 分布式键值存储

etcd 是 K8s 的"真理之源"（source of truth），存储了所有集群状态数据。

• 架构：基于 Raft 共识算法实现分布式一致性，通常部署 3 或 5 节点奇数副本
• 数据结构：以 /registry/<resource>/<namespace>/<name> 格式存储的 key-value
• Watch 机制：K8s 的核心通信模式。客户端通过 ListWatch 接口，先获取资源的完整列表，然后通过 HTTP/2 长连接监听后续变更事件（Added/Modified/Deleted）。这使得 Controller、Scheduler 等组件能够实时感知状态变化，而无需轮询
• 性能考量：etcd 对磁盘 I/O 延迟非常敏感，建议使用 NVMe SSD，并控制 key 大小（不超过 1.5MB）。大型集群需关注 etcd 的 --quota-backend-bytes（默认 8GB）

2.3 kube-scheduler — 调度器

Scheduler 负责将新创建的 Pod 分配到合适的节点。调度过程分为两个高层步骤：

1. 过滤（Filtering）：选出满足 Pod 资源需求和约束条件的可行节点
2. 打分（Scoring）：从可行节点中为 Pod 选出最合适的节点
3. 绑定（Binding）：将 Pod 绑定到选中的节点

K8s 通过 Scheduling Framework（调度框架） 实现可插拔的调度逻辑，完整的扩展点如下：

调度周期（Scheduling Cycle） — 为 Pod 选择一个节点：

1. PreEnqueue：Pod 进入调度队列前的预处理（如 Namespace 级检查）
2. QueueSort：调度队列排序，决定 Pod 的调度优先级
3. PreFilter：预处理 Pod 信息，检查基本条件（如 NodeSelector）
4. Filter（过滤）：过滤掉不满足条件的节点 — 如资源不足（CPU/Memory requests）、端口冲突、污点（Taint）不匹配
5. PostFilter：过滤后无可用节点时的处理（如抢占低优先级 Pod）
6. PreScore：打分前准备，生成打分所需的基础数据
7. Score（打分）：对通过过滤的节点打分，考量因素包括资源余量、亲和性规则、inter-pod 反亲和性等
8. NormalizeScore：打分后标准化，使不同插件的分数可比较
9. Reserve：预占资源，在绑定前锁住节点上的资源避免冲突
10. Permit：准入检查，可在此阶段批准/拒绝/等待调度决策

绑定周期（Binding Cycle） — 将 Pod 绑定到选中的节点（异步执行）：

1. PreBind：绑定前处理，如挂载网络卷
2. Bind：Scheduler 调用 API Server 将 Pod 绑定到目标节点
3. PostBind：绑定后清理，如通知外部系统

调度策略示例： 以下配置告诉 Scheduler "只把 Pod 调度到有 NVMe SSD 硬盘的节点上"——通过节点标签和亲和性规则实现。

# 节点亲和性
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk-type
            operator: In
            values:
            - nvme-ssd

2.4 kube-controller-manager — 控制器管理器

K8s 的核心设计哲学是声明式 API + 控制器模式。Controller Manager 内部包含数十个控制器。从逻辑上讲，每个控制器都是一个独立的进程，但为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。每个控制器都遵循Reconciliation Loop（调谐循环） 模式：

观察当前状态 → 与期望状态比较 → 执行操作 → 再次观察

关键内置控制器：

控制器	职责
Deployment Controller	管理 ReplicaSet 的创建、滚动更新、回滚
ReplicaSet Controller	确保指定数量的 Pod 副本运行
StatefulSet Controller	管理有状态应用的 Pod 序号、稳定网络标识
Node Controller	监控节点健康，NodeHeartbeat 超时后标记 NotReady
EndpointSlice Controller	维护 Service 后端 Pod 的 IP 地址列表
Namespace Controller	管理命名空间的生命周期
ServiceAccount Controller	自动为命名空间创建 default ServiceAccount
PV Controller	处理 PV/PVC 的绑定和回收
Job Controller	管理一次性任务的 Pod

2.5 cloud-controller-manager — 云控制器管理器

云控制器管理器（CCM）是控制平面的可选组件，负责将集群连接到云提供商的 API，实现云平台特定的控制逻辑。它的设计初衷是将与云平台交互的控制器从 kube-controller-manager 中分离出来，使核心控制器保持云平台无关。

仅在公有云环境需要，裸金属或本地部署的集群不包含此组件。

包含的控制器：

控制器	职责
Node Controller	当节点失联时，查询云平台 API 确认节点是否被云服务商删除
Route Controller	在云平台 VPC 中配置路由规则，使不同节点上的 Pod 可以互通
Service Controller	自动为 LoadBalancer 类型的 Service 创建、更新、删除云负载均衡器

CCM 同样支持水平扩缩以提升性能或增强容错。

---

3. 工作节点组件

3.1 kubelet — 节点代理

kubelet 是运行在每个节点上的主代理，负责管理该节点上所有 Pod 的生命周期。它通过 CRI（Container Runtime Interface） 与容器运行时交互，通过 CNI（Container Network Interface） 配置网络，通过 CSI（Container Storage Interface） 管理存储卷。

kubelet 的核心流程：

API Server (Watch Pod 变更)
       │
       ▼
  Pod 同步循环 (~1s 间隔)
       │
       ├── Pod 状态上报（Status Manager）
       ├── 容器创建/更新（通过 CRI）
       ├── 存储卷挂载（通过 CSI）
       ├── 网络配置（通过 CNI）
       ├── 健康检查（Liveness/Readiness/Startup Probe）
       └── 资源统计（cAdvisor → metrics）

关键配置参数：

• --node-status-update-frequency：节点状态上报频率（默认 10s）
• --image-gc-high-threshold：镜像 GC 磁盘使用率上限（默认 85%）
• --eviction-hard：驱逐策略阈值（如 memory.available<100Mi）

3.2 kube-proxy — 网络代理（可选）

kube-proxy 实现 Service 的 VIP 到后端 Pod IP 的路由。它不是必须的 — 部分网络插件（如 Cilium、Calico eBPF 模式）直接替代了 kube-proxy 的流量代理功能，使用这些插件时节点可不运行 kube-proxy。支持以下模式：

• iptables（默认）：通过 iptables NAT 规则转发流量，性能稳定但规则量多时更新开销大
• IPVS：基于内核 IP Virtual Server，性能更高，适合大规模 Service（数千条规则）
• nftables：iptables 的后继者，使用内核 nf_tables API，性能优于 iptables
• userspace：用户态代理，性能差，自 v1.24 起已从代码中移除

3.3 容器运行时（Container Runtime）

K8s 通过 CRI 接口与容器运行时解耦。常用实现：

• containerd：Docker 剥离出的核心运行时，目前最主流
• CRI-O：专为 K8s 优化的轻量运行时
• Docker：通过 cri-dockerd 适配器支持（已弃用）

3.4 插件（Addons）

插件使用 K8s 原生资源（DaemonSet、Deployment 等）实现集群级别的功能，属于"内置但可选"的组件：

• 集群 DNS（CoreDNS）：为 Pod 提供 DNS 解析和 Service 名称到 ClusterIP 的映射，是所有 K8s 集群的标配
• Web 界面（Dashboard）：基于 Web 的集群管理界面，详见 Kubernetes RBAC 权限与安全
• 容器资源监控：通过 Metrics Server 暴露 Pod/Node 的 CPU 和内存指标，是 HPA 自动扩缩容的基础，详见 Kubernetes 监控体系
• 网络插件（CNI）：Calico、Flannel、Cilium 等，负责实现 Pod 间通信，详见 Kubernetes 网络模型

---

4. CRD 与 Operator 模式

Kubernetes 的可扩展性不仅体现在其架构之上，更在于可通过 CRD（Custom Resource Definition） 扩展 API，通过 Operator 扩展控制逻辑。

CRD 允许用户定义全新的资源类型（如 VerticaDB、Prometheus）。一旦注册，这些自定义资源就能像原生资源一样通过 kubectl 访问。

Operator 则是在 CRD 之上运行的自定义控制器，它：

1. Watch 自定义资源的状态变化
2. 执行运维操作（创建 StatefulSet、配置 Service、管理备份等）
3. 将实际状态调谐至期望状态

典型案例： VerticaDB Operator。当用户创建以下 CR 时：

apiVersion: vertica.com/v1beta1
kind: VerticaDB
spec:
  subclusters:
    - name: analytics
      size: 5
  communal:
    path: "s3://my-bucket/vertica/"

Operator 会自动创建 5 个 Pod 的 StatefulSet、配置 Service、初始化 Vertica 数据库、创建子集群。这就是 Operator 模式的威力 — 将应用领域的运维知识编码为自动化逻辑。

更多关于 CRD 和 Operator 的使用，请参考 Vertica Eon on K8s 生产部署实战 以及 Vertica on Kubernetes 的入门教程。

---

5. 总结

层次	核心组件	关键机制
控制平面	API Server, etcd, Scheduler, Controller Manager, Cloud Controller Manager	Watch 机制、声明式 API、调谐循环
工作节点	kubelet, kube-proxy（可选）, 容器运行时	CRI/CNI/CSI 接口、健康检查
Addons	CoreDNS, Dashboard, Metrics Server, CNI 插件	集群 DNS、监控指标、Web 管理、Pod 网络
扩展	CRD, Operator	自定义资源、自动化控制器

理解这些核心组件及其交互方式，是后续学习 Pod 调度、网络、存储等进阶主题的基础。

---

→ 下一篇文章： Kubernetes Pod 与 Deployment 实战 — 学习最小的部署单元 Pod 和声明式工作负载 Deployment。