系列导航

本系列从 K8s 存储模型入手，逐步展开到 CSI 标准与云原生存储全景。

① 概念 → ② Volume 生命周期 → ③ CSI 架构 → ④ FlexVolume 演进 → ⑤ 对比 → ⑥ 排障 ‖ ⑦ 开发 → ⑧ 高级特性 → ⑨ 演进展望

重要

本文是系列地基，回答一个问题：K8s 怎么管理持久化存储，CSI 又是什么。

脉络按两条线索展开，在 Pod 怎么用上存储 处汇合：

• 自底向上——找出问题：物理存储 → 文件系统 → K8s Volume → Pod 挂载 → 为什么需要 PV/PVC 抽象
• 自顶向下——给出方案：K8s 存储模型 → PV/PVC/StorageClass → Volume 生命周期 → CSI 标准

先补齐 K8s 存储基础概念，再看 PV/PVC 体系解决什么问题，最后给出 CSI 标准的全貌。后续文章按 CSI 架构的枝叶逐一深入。

1. K8s 存储模型

1.1 容器为什么需要持久化存储

容器的设计原则是"无状态"——容器销毁后，容器文件系统内的数据随之消失。但现实中有大量应用需要持久化数据：

K8s 通过 Volume 机制解决容器持久化存储问题。Volume 是 Pod 的一部分，生命周期独立于容器——容器重启不丢失，Pod 删除才释放。

1.2 Volume：Pod 级别的存储声明

Volume 定义在 Pod 的 spec.volumes 字段中，容器通过 volumeMounts 挂载：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      hostPath:
        path: /data/html

K8s 内置约 20 种 Volume 类型：

1.3 Volume 的局限：为什么需要 PV/PVC

直接在 Pod YAML 里声明 Volume 类型存在三个问题：

PV/PVC 体系就是为解决这些问题而设计的。

2. PV/PVC/StorageClass 体系

2.1 三个核心对象

三者的关系类似"面向对象"：

PVC = 接口（我要什么存储）
PV  = 实现（具体的存储资源）
SC  = 工厂（怎么自动生产 PV）

2.2 PV 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 10.244.1.4
    path: "/"

2.3 PVC 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

2.4 绑定机制

PVC 和 PV 的绑定由 PersistentVolumeController 控制循环完成。绑定条件：

绑定后，Pod 通过 volumes.persistentVolumeClaim.claimName 引用 PVC：

1
2
3
4

volumes:
  - name: data
    persistentVolumeClaim:
      claimName: nfs-pvc

2.5 AccessModes（访问模式）

3. StorageClass 与动态供应

3.1 静态供应 vs 动态供应

3.2 StorageClass 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: csi.example.com/ssd
parameters:
  type: ssd
  replication: zonal
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

关键字段：

3.3 动态供应流程

1. 开发创建 PVC（指定 StorageClass）
2. PersistentVolumeController 发现未绑定的 PVC
3. External Provisioner（Sidecar）监听 PVC，匹配 StorageClass 的 provisioner
4. External Provisioner 调用 CSI 插件的 ControllerCreateVolume
5. CSI 插件在后端存储系统创建卷，返回卷信息
6. External Provisioner 创建 PV 对象
7. PersistentVolumeController 将 PV 与 PVC 绑定
8. Pod 调度后，Kubelet 调用 CSI 插件执行 Attach + Mount

4. 存储分类树

K8s 的持久化存储方案可以从两个维度分类：

4.1 按存储接口分类

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

K8s 存储方案
├── 内置 Volume 插件（K8s 代码内实现）
│   ├── hostPath / emptyDir（本地临时）
│   ├── nfs / iscsi / cephfs / rbd（网络存储）
│   └── configMap / secret / downwardAPI（配置数据）
│
├── FlexVolume（脚本式插件，已废弃）
│   └── 可执行文件放在宿主机固定路径，Kubelet 调用
│
└── CSI（Container Storage Interface，标准 gRPC 接口）
    ├── 块存储 CSI（Ceph RBD、EBS、vSphere）
    ├── 文件存储 CSI（NFS、CephFS、AzureFile）
    └── 对象存储 CSI（S3、MinIO）

4.2 按存储类型分类

4.3 CSI 解决的三件事

CSI 标准本质上解决三件事：

所有 CSI 插件的能力都可以归到这三个维度。后续文章按 CSI 架构的枝叶逐一深入。

5. CSI 与 CNI 的类比

如果读者已了解 CNI（Container Network Interface），可以通过类比快速理解 CSI：

6. 系列文章脉络

本文建立了 K8s 存储的基础概念。后续文章按以下脉络展开：

参考链接

• Kubernetes Storage 概念文档
• CSI 规范
• Kubernetes PV/PVC 设计文档