存储系统

容器 = 镜像层(只读) + 容器层(可写,用 OverlayFS 叠加)

┌─────────────────────────────────┐
│  容器层(可写 Upper Layer)       │  ← 容器运行时的所有写入都在这里
│  /tmp/data.txt ← 你写的文件      │
├─────────────────────────────────┤
│  镜像层 3(只读)                 │
├─────────────────────────────────┤
│  镜像层 2(只读)                 │  ← 镜像构建时的各层
├─────────────────────────────────┤
│  镜像层 1(只读)- Base Image     │
└─────────────────────────────────┘

问题:容器层随容器生命周期存在
  容器被删除(Pod 重建/重启) → 容器层消失 → 你写的所有文件全部丢失

没有 Volume:
  容器文件系统 = 镜像层 + 容器层(临时)
  容器重启 → 数据丢失

有 Volume:
  容器文件系统 = 镜像层 + 容器层 + Volume(挂载到 /data)
  容器重启 → 容器层丢失,但 /data 目录的内容来自 Volume → 数据保留

Volume 的生命周期取决于类型:
  emptyDir  → 随 Pod 存在(Pod 删除则丢失)
  hostPath  → 随节点存在(Pod 调度到其他节点则看不到)
  PVC       → 独立于 Pod 和节点(真正的持久化)

生命周期:
  Pod 创建 → emptyDir 创建(空的)
  容器写入 /data → 实际写入节点的 /var/lib/kubelet/pods/<pod-id>/volumes/...
  容器崩溃重启 → emptyDir 内容保留(因为 Pod 还在)
  Pod 被删除 → emptyDir 一起删除 → 数据丢失

适用场景:
  ✓ 同一 Pod 内多个容器需要共享文件(如 sidecar 模式)
  ✓ 临时缓存/中间计算结果(丢了也没关系)
  ✓ 排序算法需要的临时磁盘空间
  ✗ 需要持久化的数据(数据库,用户上传文件)

开发者写:                          管理员/StorageClass 提供:
┌──────────────────────┐          ┌──────────────────────────────┐
│  PVC                 │          │  PV                          │
│  "我要 100Gi, RWO"   │── 绑定 ──│  AWS EBS vol-0123, 100Gi, RWO │
└──────────────────────┘          └──────────────────────────────┘
         ↑
    Pod 引用 PVC

Retain 策略下 PV 的状态流转:
  Available → Bound → Released → (手动清理后)Available
                ↑                          ↓
              PVC 创建并绑定           PVC 删除,PV 释放但不清除数据
                                      需要管理员手动处理:
                                        - 备份数据
                                        - 删除 PV 的 claimRef 字段
                                        - PV 重新变为 Available

Delete 策略下:
  Available → Bound → PVC 删除 → PV 和底层存储一起销毁
                                  (不可恢复!)

PVC 创建后,PV Controller 执行绑定逻辑:

1. 查找匹配的 PV:
   - capacity >= PVC 请求的 storage
   - accessModes 包含 PVC 要求的模式
   - storageClassName 匹配
   - PV 状态为 Available

2. 绑定:
   - PV.spec.claimRef 指向这个 PVC
   - PVC.spec.volumeName 指向这个 PV
   - 两者状态都变为 Bound
   - 绑定是一对一的:一个 PV 只能绑定一个 PVC

3. 如果找不到匹配的 PV:
   - 如果 StorageClass 支持动态供给 → 自动创建 PV(见下节)
   - 如果不支持 → PVC 一直处于 Pending 状态

完整链路(Pod → PVC → PV → 实际存储):

  Pod spec:
    volumes:
    - persistentVolumeClaim:
        claimName: mysql-data       ← 引用 PVC
            │
            ↓
  PVC "mysql-data":
    volumeName: pv-ebs-100          ← 绑定到 PV
            │
            ↓
  PV "pv-ebs-100":
    csi:
      driver: ebs.csi.aws.com
      volumeHandle: vol-012345      ← 实际的 AWS EBS 卷 ID
            │
            ↓
  AWS EBS 云盘 vol-012345
    → 挂载到 Pod 所在节点 → 格式化为 ext4 → mount 到容器的 /var/lib/mysql

开发者创建 PVC(指定 storageClassName: gp3)
     ↓
PV Controller 发现没有现成 PV 匹配
     ↓
调用 StorageClass "gp3" 的 provisioner(ebs.csi.aws.com)
     ↓
CSI 驱动调用 AWS API → 创建一块新的 EBS gp3 卷(100Gi)
     ↓
CSI 驱动创建对应的 PV 对象(自动填入 volumeHandle)
     ↓
PV Controller 将 PVC 和新 PV 绑定
     ↓
Pod 调度到节点后,kubelet 通过 CSI 将 EBS 卷 attach 到节点并 mount

全过程:开发者只写了一个 PVC → 剩下全部自动完成

┌──────────────────────────────────────────────────────────────────┐
│ 集群管理员 / 云平台                                                │
│                                                                  │
│  StorageClass "gp3"                                              │
│    provisioner: ebs.csi.aws.com                                  │
│    parameters: {type: gp3, encrypted: true}                      │
│    reclaimPolicy: Retain                                         │
│                                                                  │
│  → 定义了"动态创建 PV 的模板"                                      │
│  → 管理员只需要创建一次,后续全自动                                  │
└────────────────────────────────────┬─────────────────────────────┘
                                     │ PVC 触发动态供给
                                     ↓
┌──────────────────────────────────────────────────────────────────┐
│ 应用开发者                                                        │
│                                                                  │
│  PVC "mysql-data"                                                │
│    storageClassName: gp3                                         │
│    requests.storage: 100Gi                                       │
│    accessModes: [RWO]                                            │
│                                                                  │
│  → "我要 100Gi RWO 的存储,从 gp3 这个 StorageClass 拿"           │
│  → 开发者不需要知道底层是 EBS / Ceph / NFS                         │
└────────────────────────────────────┬─────────────────────────────┘
                                     │ 自动创建 + 绑定
                                     ↓
┌──────────────────────────────────────────────────────────────────┐
│ 自动生成                                                          │
│                                                                  │
│  PV "pvc-a1b2c3d4-..."(动态生成的名称)                           │
│    capacity: 100Gi                                               │
│    csi.volumeHandle: vol-0987654321                              │
│    claimRef: default/mysql-data                                  │
│                                                                  │
│  → 指向真实的 AWS EBS 卷                                          │
│  → 和 PVC 一对一绑定                                              │
└──────────────────────────────────────────────────────────────────┘

StatefulSet 创建 3 个副本时的行为:

  mysql-0 → 自动创建 PVC "data-mysql-0" → 触发动态供给 → 创建 PV + EBS 卷
  mysql-1 → 自动创建 PVC "data-mysql-1" → 触发动态供给 → 创建 PV + EBS 卷
  mysql-2 → 自动创建 PVC "data-mysql-2" → 触发动态供给 → 创建 PV + EBS 卷

  每个 Pod 有独立的 PVC → 独立的 PV → 独立的磁盘 → 数据隔离

  mysql-1 挂了重建:
    新 Pod 仍叫 mysql-1 → 找到 PVC "data-mysql-1"(还在)→ 重新挂载 → 数据恢复

  缩容到 1 个副本:
    data-mysql-1 和 data-mysql-2 PVC 保留不删(防止误删数据)
    重新扩容到 3 → 复用已有 PVC → 数据原样恢复

扩容流程:
  1. PVC requests.storage: 100Gi → 200Gi
  2. CSI Controller 调用云平台 API 扩容底层磁盘(EBS Modify Volume)
  3. kubelet 检测到容量变化 → 在线扩展文件系统(resize2fs / xfs_growfs)
  4. 完成,无需重启 Pod

注意:
  - 只能扩容,不能缩容(缩容会丢数据)
  - 部分存储后端需要 Pod 重启后才能完成文件系统扩展
  - 扩容过程中 PVC 状态会短暂变为 FileSystemResizePending

CSI 出现之前:
  存储逻辑写死在 K8s 核心代码中(in-tree)
  → 新增存储后端需要改 K8s 源码 + 等新版本发布
  → 维护困难,存储厂商无法独立迭代

CSI 出现之后:
  K8s 核心只定义接口(gRPC 协议)
  → 存储厂商实现 CSI 驱动(独立部署为 Pod)
  → 新增/升级存储后端不需要动 K8s 本身

类比:
  USB 接口标准 → 任何厂商按标准做 U 盘就能用
  CSI 接口标准 → 任何厂商按标准做驱动就能接入 K8s

CSI 驱动由两部分组成:

┌─────────────────────────────────────────────────┐
│ CSI Controller(Deployment,1-2 副本)            │
│   职责:                                         │
│   - CreateVolume:调用云 API 创建磁盘             │
│   - DeleteVolume:调用云 API 删除磁盘             │
│   - ControllerPublishVolume:Attach 磁盘到节点    │
│   - ExpandVolume:扩容                           │
└─────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────┐
│ CSI Node(DaemonSet,每节点一个)                  │
│   职责:                                         │
│   - NodeStageVolume:格式化磁盘(如 mkfs.ext4)   │
│   - NodePublishVolume:Mount 到容器目录           │
│   - NodeUnpublishVolume:Unmount                 │
└─────────────────────────────────────────────────┘

选型决策树:

  数据需要持久化吗?
       │
       ├── 否 → emptyDir(临时缓存,容器间共享)
       │
       └── 是 → 需要多 Pod 同时读写吗?
                    │
                    ├── 否(单 Pod 读写)→ RWO 块存储
                    │       适合:数据库,单实例有状态服务
                    │       后端:EBS / 云硬盘 / Ceph RBD
                    │
                    └── 是(多 Pod 读写)→ RWX 文件存储
                            适合:共享文件,CMS 媒体,ML 训练数据
                            后端:NFS / EFS / CephFS / GlusterFS