第 6 章 · 01 集群架构与核心对象

第 6 章 · 01 集群架构与核心对象

理解 Kubernetes 的第一把钥匙是"分工"：控制平面负责决策，工作节点负责执行；第二把钥匙是"声明式"：你描述期望状态，控制器负责收敛。本节先解剖集群架构，再逐个认识六类工作负载对象——它们构成日常操作的主战场。

学习目标

• 说出控制平面与工作节点各组件的职责
• 理解控制器"观察-对比-行动"的控制循环
• 分清 Pod/ReplicaSet/Deployment/DaemonSet/StatefulSet/Job 的定位
• 掌握 Pod 的生命周期阶段与删除宽限期机制

一、集群架构：大脑与四肢

Kubernetes 集群由两类节点组成：**主节点（控制平面，Control Plane）**负责协调集群内所有工作流——调度应用、管理期望状态、滚动发布新更新；**工作节点（Worker/Data Plane）**实际运行应用。最小集群 = 1 主 + 1 工作节点；生产环境建议至少 3 个主节点。

控制平面四大组件：

工作节点三大组件：

etcd 值得多说两句：它保存集群当前状态（应用数据不存其中），选择它的理由是高可用（多节点部署）、全复制（每节点可读全量）、强一致（读到的总是最新数据）、安全（支持 TLS）与高性能（上万次写入/秒）。

控制器循环是整个系统的心脏：任何控制器都在做"Observe（观察）→ Diff（对比期望与实际）→ Act（行动）"三件事。Node Controller 监控节点健康、节点不可达时疏散其 Pod；Replication Controller 保证副本数——都是这个循环的具体实例。记住这个模式，后面所有对象的行为都可以推导出来。

二、Pod：最小的调度单元

Pod 是 Kubernetes 可创建和管理的最小计算单元：一组共享存储和网络资源、按同一规范运行的一个或多个容器。三个关键认知：

container 不是 K8s 对象——没有 kubectl get containers 命令，Pod 才是最小对象。多容器 Pod 用 sidecar 模式（日志、监控适配器）承载辅助职责。

一个 Pod 只运行在一个节点上，不能被拆到多个节点；一旦绑定节点，即使失败重启也只在该节点运行。

直接创建 Pod 不常见——Pod 死亡后 Kubernetes 不会自动复活它，保证副本数的职责在 ReplicaSet/Deployment 手里。

Pod 的生命周期阶段：

删除 Pod 不是即时的：发送 TERM 信号 → 每个容器有 30 秒优雅关闭宽限期 → 超时后 KILL 强杀。给应用留出"处理完存量请求再退"的时间窗。

三、ReplicaSet：副本的保证者

ReplicaSet 的目标一句话：在任何时刻维持稳定的一组副本 Pod。多于定义数就删除多余的，少于定义数就补建新的。规则细节是判断题密集区：

• spec.template 是必填字段（RS 靠它创建新 Pod）；默认副本数为 1；
• 直接删 RS 的 Pod，RS 会立刻重建；
• selector 匹配的 Pod 不必由 RS 自己创建——它按标签"认领"；
• 移除 Pod 上被 selector 使用的标签，RS 会认为"丢失"该 Pod 并新建一个；
• 删除 RS 默认级联删除其创建的 Pod，--cascade=false 可保留。

调优命令：kubectl scale rs --replicas=5 扩缩容；kubectl describe rs 的 Events 末尾能看到 RS 是"找到了匹配 Pod"还是"新建了 Pod"——排障时先看这里。

四、Deployment：声明式发布的载体

Deployment 声明式地声明 Pod 和 ReplicaSet 的期望状态：可扩缩副本、受控滚动发布、必要时回滚。管理关系是层级式的：Deployment 管理 ReplicaSet，ReplicaSet 管理 Pod（新版 RS 取代了旧的 ReplicationController）。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
​

改镜像（kubectl edit deployment）后发生的事：旧 Pod 终止、新 Pod 创建、旧 RS 清空、新建一个 RS——Deployment 的版本历史以 RS 为单位保留，回滚 = 切回旧 RS。

两个高频陷阱：kind 写错（Deploy 应为 Deployment）；selector 与 template 的标签不匹配——这会导致 RS 认领不到任何 Pod。

五、DaemonSet 与 StatefulSet：两极的保证

DaemonSet 保证"每个节点恰好一个 Pod"：节点加入自动补 Pod，节点移除自动清理。与 ReplicaSet 的区别：RS 保证"任意位置 N 个副本"，DS 保证"每个节点一份"。典型场景：监控 agent（每个节点采集指标）、日志采集、CNI 网络组件。实现方式：1.12 之前靠 NodeName 属性，之后用常规调度器 + node affinity。

StatefulSet 管理有状态应用，提供关于 Pod 顺序与唯一性的保证：稳定的网络标识（Pod 名固定、序号递增）、稳定的存储（每个副本绑定专属卷）。数据库、ZooKeeper 这类有身份状态的应用用它。

六、Job 与 CronJob：跑完就走的任务

Job 管理一次性任务：跑完即 Succeeded。CronJob 按 cron 格式周期创建 Job——一条 CronJob 约等于 crontab 的一行。两个容易踩的坑：

并发策略：concurrencyPolicy 默认 Allow 时，若 Job 失败，下一个周期不会替换上一个，失败 Job 持续堆积最终填满集群——应改为 Forbid 或 Replace。

字段位置：concurrencyPolicy、successfulJobsHistoryLimit、failedJobsHistoryLimit 必须放在 CronJob 的 spec 下（与 schedule 同级），放进 jobTemplate 里不生效——没有历史限制会导致资源无限累积甚至 OOM。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: some-cron-job
spec:
  schedule: '*/1 * * * *'
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 1
  failedJobsHistoryLimit: 1
​

小结

本节建立了 Kubernetes 的世界观：控制平面决策、工作节点执行、控制器循环收敛；六类工作负载各司其职——Pod 是最小单元、RS 保副本、Deployment 管发布、DaemonSet 保每节点一份、StatefulSet 保有状态身份、Job/CronJob 管一次性任务。对象认识了，下一个问题是：Pod 到底怎么被放到节点上、流量怎么进来——调度与网络是下一节的主题。

下一节预告

第 6 章第 2 节《调度网络与服务暴露》将完整走一遍"kubectl run 之后发生了什么"，讲解三种调度手段、Service 四种类型与 Ingress 外部入口。