存储与状态：控制循环的又一次复用

第 2 章给出了贯穿全书的那把钥匙: Kubernetes 是一组 level-triggered 的控制循环——每个控制器读取「期望状态」与「实际状态」，算出差异，朝期望收敛(reconcile)，然后再读一遍。无状态对象(Deployment/ReplicaSet/Pod)是这套机制最干净的展示场。本章把同一把钥匙插进一把看似不同的锁: 配置注入与持久存储。结论先摆出来——存储并不是另起炉灶的新机制，PVC 与 PV 的绑定本身就是又一个 reconcile 循环。把这一点看穿，本章的大半内容就只是第 2 章的换皮复述。

5.1配置注入与「改了不生效」的失败模式

ConfigMap/Secret 把配置从镜像里剥离出来，通过环境变量或挂载卷注入容器；但注入方式决定了它改了之后会不会生效。

两种注入方式的代码形态如下——同一个 ConfigMap，既可以摊平成环境变量，也可以挂成目录里的文件。

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  config.yaml: |
    server:
      timeout: 30s
---
apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:                          # 路线 A：注成环境变量
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: LOG_LEVEL
      volumeMounts:                 # 路线 B：挂成卷（文件）
        - name: cfg
          mountPath: /etc/app
  volumes:
    - name: cfg
      configMap:
        name: app-config

差别在于生效时机，而这正是第 2 章控制循环视角能一眼看穿的地方。

环境变量在容器启动那一刻只读一次。 kubelet 创建容器时把 LOG_LEVEL 的值固化进进程环境，此后这个值就是进程内存里的一个常量。现在去 kubectl edit configmap app-config 把它改成 debug——什么都不会发生。关键在于: 改 ConfigMap 没有改动任何 Pod 的 spec 字段。Deployment 控制器盯的是 Pod 模板的 spec，spec 没变，diff 为空,reconcile 认为「实际已等于期望」,于是不滚动、不重建 Pod。运行中的容器里那个环境变量,纹丝不动。

挂载成卷的 key 文件会更新——但只更新到一半。kubelet 有一个周期性的同步循环，会把 ConfigMap 的新内容刷新到挂载卷的文件里(通过原子替换符号链接，存在最长约一分钟的传播延迟)。所以 /etc/app/config.yaml 的文件内容确实变了。可应用进程通常是在启动时把配置文件读进内存就不再回看——文件变了，进程内的配置没变。除非应用自己实现了 watch/inotify 或 SIGHUP 重载，否则新值同样躺在磁盘上睡大觉。

方案 ② 的哈希注解值得单独点出,因为它把失败模式的成因直接翻译成了修复手段: 既然 reconcile 只认 spec 变化,那就让配置的内容参与到 spec 里去。

spec:
  template:
    metadata:
      annotations:
        # 配置内容的哈希；ConfigMap 一改，这个值就变，
        # Pod 模板的 spec 随之改变 → 自动触发滚动更新
        checksum/config: "5d41402abc4b2a76b9719d911017c592"

5.2Volume 与 PV/PVC 绑定: 存储就是又一次 reconcile

PV 是「一块已存在或可被供给的存储」(供给),PVC 是「应用对存储的申领」(期望);一个控制平面循环把二者按容量、访问模式、StorageClass 一对一双向绑定——这跟第 2 章的控制循环是同一个模式。

把这两个对象并排看,第 2 章的句式立刻浮出来: PVC 是期望状态、PV 是实际供给,中间缺的那一步——撮合——正是一个 reconcile 循环干的活。 这个循环叫 PV 控制器(PersistentVolume controller),它的工作和 Deployment 控制器在结构上一模一样: 读一批未绑定的 PVC(期望) 与一批可用的 PV(实际),按规则算出哪个 PV 满足哪个 PVC,然后把它们绑定(写入双向引用),再循环。

撮合的判据是几个硬约束的交集,绑定必须同时满足:

• 容量: PV 的 capacity ≥ PVC 申请的容量。
• 访问模式: PV 支持的 accessModes 覆盖 PVC 要求的——RWO(ReadWriteOnce,单节点读写)、ROX(ReadOnlyMany)、RWX(ReadWriteMany)。
• StorageClass: 两者的 storageClassName 必须一致。
• 选择器/卷模式等其余约束(如有)也要匹配。

绑定一旦达成,就是一对一且排他的: PV 的 spec.claimRef 指回那个 PVC,PVC 的 spec.volumeName 指向那个 PV——双向引用焊死,别的 PVC 再也绑不上这个 PV。这正是「一块盘只能被一个申领占用」在对象层面的实现。

apiVersion: v1
kind: PersistentVolume           # 供给侧：实际存在的一块存储
metadata:
  name: pv-data
spec:
  capacity:
    storage: 20Gi
  accessModes: ["ReadWriteOnce"]
  storageClassName: standard
  # ...底层来源（nfs / hostPath / csi ...）
---
apiVersion: v1
kind: PersistentVolumeClaim      # 期望侧：应用的申领
metadata:
  name: data-claim
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: standard
  resources:
    requests:
      storage: 10Gi              # 要 10Gi，pv-data 的 20Gi 能满足 → 绑定

PV 的生命周期是一台明确的状态机,相位(status.phase) 在控制循环的推动下流转:

• Available: 空闲,等待被某个 PVC 绑定。
• Bound: 已与一个 PVC 绑定,正被使用。
• Released: 绑定它的 PVC 被删了,但 PV 上的数据还没按回收策略(persistentVolumeReclaimPolicy: Retain/Delete) 处理,因此尚不可被重新绑定。
• Failed: 自动回收过程出错。

5.3StorageClass 与动态供给

没有人工预备 PV 时,PVC 指定一个 StorageClass,provisioner 按需即时创建出一块 PV 再绑定——把「先备货」变成「按订单生产」。

动态供给把绑定循环又拆细了一层。当一个 PVC 指定了 StorageClass 而集群里没有现成 PV 能满足它时,流程是:

• PVC 提交,带 storageClassName: fast-ssd,此刻没有匹配的 Available PV。
• 该 StorageClass 指定的 provisioner(通常是一个 CSI 驱动)观察到这个待供给的 PVC。
• provisioner 真的去后端(云厂商 API、存储阵列等)即时创建一块满足规格的盘,并据此生成一个对应的 PV 对象。
• 新 PV 一出现,§5.2 那个绑定循环立刻把它和 PVC 绑上。PVC 从 Pending 转为 Bound。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: ebs.csi.aws.com         # 由谁来「造盘」
parameters:
  type: gp3
reclaimPolicy: Delete                # PVC 删除后，连同盘一起删
volumeBindingMode: WaitForFirstConsumer   # 等 Pod 被调度后再供给（见下）
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-claim
spec:
  storageClassName: fast-ssd         # 下订单：没有现成 PV 就动态造一个
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 10Gi

代价与一个关键参数。 动态供给把存储的创建权交给了 provisioner,便利的反面是: 这些盘通常是真实计费资源,reclaimPolicy: Delete 意味着删 PVC 会连数据盘一起删掉(对数据库这类场景应改用 Retain)。另一个常被忽略的参数是 volumeBindingMode: 默认 Immediate 会在 PVC 一提交就立刻供给——可此时 Pod 还没调度,造出的盘会落在一个未必能被 Pod 触达的可用区,导致后续挂载失败。WaitForFirstConsumer 把供给推迟到 Pod 被调度之后,让存储跟着 Pod 的落点走——这又一次呼应了第 3 章调度与第 4 章拓扑: 各控制循环的决策彼此牵连。

5.4StatefulSet vs Deployment: 谁给 Pod 稳定身份

Deployment 的 Pod 是可互换的、躲在一个 ReplicaSet 后、共享同一个 PVC;StatefulSet 给每个 Pod 稳定且唯一的身份——序号、主机名、专属 PVC——并按序操作。

两者的机制差异集中在身份这一个词上。Deployment → ReplicaSet → Pod 这条链里,Pod 名字是随机后缀(如 web-7d9f8-x2k4p),挂了重建就换一个全新名字,所有副本通过 Service 共享一个负载均衡入口、且常常共用同一个 PVC。StatefulSet 则给每个 Pod 一套黏在它身上、跨重建保持不变的身份:

• 有序序号 + 稳定主机名: 副本被命名为 web-0、web-1……web-(N-1)。web-0 挂了重建,新 Pod 仍叫 web-0。
• 每 Pod 专属 PVC: 通过 volumeClaimTemplates,StatefulSet 为每个 Pod 单独创建一个 PVC(data-web-0、data-web-1……),Pod 重建后重新绑回自己原来那一个,数据不丢、不混。
• 有序滚动: 创建按 0→N-1 顺序、删除按 N-1→0 逆序、升级逐个进行,保证集群成员关系的有序变更。
• 配合 headless Service: clusterIP: None 的 Service 不做负载均衡,而是为每个 Pod 提供一个稳定 DNS 名(web-0.svc...),让成员之间能点对点寻址。

对应的声明里,volumeClaimTemplates 是 StatefulSet 独有的字段——它不是「一个 PVC」,而是「一张为每个副本各印一份 PVC 的模板」。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: web-headless        # 配合 headless Service（clusterIP: None）
  replicas: 3
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: app
          image: myapp:1.0
          volumeMounts:
            - name: data
              mountPath: /var/lib/data
  volumeClaimTemplates:            # 关键：为每个 Pod 各建一个 PVC
    - metadata:
        name: data                 # → data-web-0, data-web-1, data-web-2
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 10Gi

5.5失败模式: 用 Deployment 跑有状态应用

给一个多副本 Deployment 挂一块 RWO 的 PVC,等于让所有副本去抢同一块只能单节点挂载的盘——结果是 Pod 卡住、调度受限、或数据互相覆盖。

把副本数从 1 调到 3,会按底层卷类型走向以下几种结局,无一是好的:

• 第 2、3 个副本卡在 ContainerCreating。 它们被调度到了别的节点,而 RWO 卷已被第一个副本所在节点独占挂载,新节点 attach 失败,Pod 永远起不来。
• 调度被强行挤到同一节点。 若靠亲和性把副本都摁在 RWO 卷所在的那个节点,就失去了多副本的容灾意义——节点一挂全挂,且单节点资源成为天花板。
• 数据互相覆盖(最危险)。 万一卷是 RWX 或某些文件系统允许多挂载,几个并不为并发写设计的应用进程同时往同一份文件/数据目录写,没有协调,数据损坏。

把本章收束回那条贯穿全书的主线: 配置注入的「改了不生效」、PV/PVC 的绑定、StatefulSet 的有序操作——没有一个引入了新范式。它们都是同一组 level-triggered 控制循环在不同对象上的展开: 控制器观察期望与实际、算差异、收敛、再观察。存储只是又一次 reconcile;有状态只是给参与 reconcile 的对象加了「身份」这一约束。第 2 章那把钥匙,到这里依然是同一把。