对象模型：你向集群声明的"名词"

Kubernetes 的核心心智模型只有一句话：它是一组 level-triggered 的控制循环——你声明期望状态(spec)，控制器持续观测实际状态(status)，并把实际推向期望。这句话贯穿整个教程。本章只负责一件事：把你"声明"时用到的名词讲清楚。这些名词就是 K8s 的对象(object)，而每一个对象都长成同一副骨架——一半是你写的期望，一半是系统回写的实际。控制循环本身留到第 2 章；这里先认全词汇表。

1.1一切皆声明式对象

在 K8s 里，你管理的一切都是一份对象记录，由 spec(期望) 与 status(实际) 两半构成。

每个对象在底层都是 etcd 里的一条记录，结构高度统一，四个顶层字段：

apiVersion: apps/v1        # 这个对象归哪个 API 组、哪个版本管
kind: Deployment           # 对象类型(名词)
metadata:                  # 身份：名字、namespace、labels
  name: web
spec:                      # ← 期望状态：你写的部分
  replicas: 3
status:                    # ← 实际状态：系统回写的部分，你别手写
  availableReplicas: 3

关键在最后两块的所有权分裂：spec 由你(或上游控制器)书写，表达"想要什么"；status 由系统持续回写，记录"现在实际是什么"。同一份对象，被两方各写一半。当你执行 kubectl apply -f web.yaml，你提交的只是 spec——表达意图(intent)，而不是"先建网络、再拉镜像、再起进程"的步骤。集群收下这份意图，剩下的"怎么把 status 变得和 spec 一致"是它的事。

这种 apply 的语义带来一个直接好处：可重复执行(幂等)。同一份 YAML 连 apply 十次，结果和一次完全相同——因为你声明的是终态，不是增量操作。改一行 replicas: 3 → 5 再 apply，集群只补上差额，不会"叠加"出 8 份。

1.2Pod — 最小调度单位

Pod 是 K8s 能调度的最小单位，是一组共享网络与存储、同生共死的容器。

底层机制：一个 pause 容器持有命名空间

同一个 Pod 内的多个容器并不是各自独立的孤岛，它们共享三类内核命名空间(namespace)：

• network namespace——共享同一个 IP 地址；容器之间可以直接经 localhost 互通，也共享同一套端口空间(所以同 Pod 内两个容器不能都监听 80)。
• IPC namespace——可通过 System V IPC / POSIX 消息队列等进程间通信原语直接通信。
• 共享 volume——挂载同一个卷，用文件系统交换数据。

这套共享靠一个不起眼的角色实现：每个 Pod 启动时，K8s 先拉起一个几乎什么都不做的 pause 容器。它的唯一职责是持有(hold)这些命名空间——业务容器随后"加入"pause 已经建好的 network/IPC 命名空间。pause 是 Pod 的"锚"：业务容器可以崩溃重启，只要 pause 活着，Pod 的 IP 和命名空间就不变。

这就解释了那条常被背诵却少有人讲清的规则：同一个 Pod 内的容器共享 localhost；不同 Pod 之间不行。因为"共享 localhost"本质是"共享同一个 network namespace",而命名空间的边界恰好就是 Pod 的边界。

情境走查：给应用配一个日志 sidecar

设想一个具体场景，逐步走一遍，留意每一步落在哪个概念上：

1. 应用容器把日志写进卷里的 /var/log/app.log(用到的概念：共享 volume)。
2. 同 Pod 里放一个 log-shipper sidecar，挂载同一个卷，读这个文件再转发到日志后端。两个容器靠文件系统交换数据,无需走网络。
3. sidecar 想确认应用是否就绪，直接请求 http://localhost:8080/healthz——因为同 Pod 共享 network namespace，localhost 就指向旁边那个 app 容器。
4. K8s 把这两个容器作为一个 Pod 整体调度到某个 Node、一起启动、一起销毁(用到的概念：Pod 作为最小调度单位、同生共死)。

若把它们拆成两个 Pod，第 2、3 步立刻失效：卷不再共享、localhost 也不再指向对方。这个场景就是 Pod 这层抽象存在的全部理由。

1.3ReplicaSet → Deployment：三层托管

ReplicaSet 维持副本数量恒定；Deployment 管理多个 ReplicaSet 来实现滚动更新与回滚。

底层机制：ReplicaSet 只做一件事

ReplicaSet 的职责单一到近乎乏味：让"标签匹配它 selector 的 Pod 数量"恒等于 spec.replicas。多了就删、少了就建。它不关心 Pod 里跑什么、是不是新版本——只数数。它怎么知道哪些 Pod 归它管？靠 label selector(下一节细讲)：凡是标签匹配的就算它的副本。

Deployment 在 ReplicaSet 之上加一层版本编排。每次你修改 Pod 模板(最常见是换镜像 tag)，Deployment 就新建一个 ReplicaSet，然后做滚动更新：

• 新 ReplicaSet 的 replicas 逐步 +1 扩容；
• 旧 ReplicaSet 的 replicas 同步 逐步缩容；
• 两条曲线一升一降，直到新 RS 满载、旧 RS 归零。

回滚就是把这个过程反向操作：旧 ReplicaSet 并没有被删除(只是 replicas 被缩到 0、留作历史),回滚时把旧 RS 重新扩容、新 RS 缩容即可。这也是为什么 kubectl rollout undo 能瞬间生效——目标版本的 RS 一直都在。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3              # → 透传给它管理的 ReplicaSet
  selector:
    matchLabels:
      app: web             # ReplicaSet 用它来"认领"Pod
  template:                # ← Pod 模板：换这里的镜像 = 触发滚动更新
    metadata:
      labels:
        app: web           # 模板里盖的标签，要能被上面的 selector 选中
    spec:
      containers:
        - name: web
          image: nginx:1.25

1.4Service：给易逝的 Pod 一个稳定身份

Service 用 label selector 选中一组 Pod，对外暴露一个稳定不变的虚拟身份。

底层机制：selector 圈定一组后端

Service 自己并不持有任何 Pod。它的 spec.selector 写一组标签条件，比如 app: web;K8s 在后台持续把"当前所有标签匹配的、就绪的 Pod 的 IP"维护成这个 Service 的后端集合。Pod 来了走了，后端列表自动增减，但 Service 对外暴露的那个地址始终不变。调用方只认 Service 的名字(如 web)或它的虚拟 IP,流量被自动分发到当前健在的某个 Pod 上。

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web            # 凡标签匹配的就绪 Pod，都成为这个 Service 的后端
  ports:
    - port: 80
      targetPort: 8080  # Service 的 80 → 转发到 Pod 的 8080

情境走查：一次滚动更新中调用方为何无感

1. 初始 3 个带 app: web 标签的 Pod,Service web 把它们作为后端。前端访问 http://web(用到的概念：稳定身份)。
2. 触发滚动更新：新 Pod 逐个起来(同样带 app: web 标签)、旧 Pod 逐个退出。Service 的 selector 不变，后端集合随标签匹配关系自动刷新(用到的概念：label selector 动态选后端)。
3. 整个过程里 Service 的名字和虚拟 IP 一个字没改,前端代码完全不用动——它访问的是身份,不是某个具体 Pod 的 IP。

1.5ConfigMap 与 Secret：把配置剥离镜像

ConfigMap/Secret 把配置与敏感数据从镜像里剥离，按环境变量或卷的形式注入 Pod。

底层机制：两种注入方式

ConfigMap 存非敏感配置,Secret 存敏感数据,二者注入 Pod 的方式相同,都有两条路：

• 作为环境变量:把键值对注入容器的 env,应用用 os.getenv 之类读取。
• 作为 volume 挂载:把每个键挂成一个文件,应用读文件。改动后文件内容会更新(env 方式则需重启容器才生效)。

1.6把对象粘起来：label/selector + Namespace + Node

label/selector 做多维分组,Namespace 划作用域边界,Node 是承载 Pod 的工作机器。

label/selector:多维、可重叠的分组

label 是打在对象上的任意 key=value 键值对;selector 是一组标签条件,用来"选出标签匹配的对象"。关键在于它是多维、可重叠的,而非单一层级:同一个 Pod 可以同时带上 app=web、tier=frontend、env=prod 三个标签,于是它同时落入三个不同维度的分组。一个 Service 的 selector 写 tier=frontend 能选中它,另一个监控规则写 env=prod 也能选中它——同一个 Pod,被不同 selector 从不同角度反复圈选。

这和你熟悉的"一个文件只能在一个目录里"截然不同。label 让分组从"树形归属"升级为"多维标记",这正是 Deployment 认领 Pod、Service 选后端、监控筛选目标——全都复用同一套机制的原因。

Namespace:作用域 / 租户边界

Namespace 是对象名字的作用域边界。同一个 Namespace 内对象名字唯一;不同 Namespace 之间可以重名(team-a/web 与 team-b/web 互不冲突)。它常用来做多团队/多环境的软隔离,也是 RBAC 权限和资源配额的作用单位。不指定时,对象落进名为 default 的 Namespace。注意:Namespace 是逻辑边界,不是物理隔离——不同 Namespace 的 Pod 默认仍可经网络互通(网络层面的隔离要靠后面章节的 NetworkPolicy)。

Node:运行 Pod 的工作机器

Node 是真正跑 Pod 的工作机器(物理机或虚拟机)。前面所有逻辑对象——Pod、ReplicaSet、Service——最终都要落到某个 Node 上运行。Node 自身也是一个对象:它的 status 持续上报这台机器的 CPU/内存容量、健康状况等,供调度决策使用。"哪个 Pod 该放到哪个 Node"是第 3 章调度的主题,本章只需把 Node 定位成"对象模型的物理落脚点"。