Kubernetes 持久化存储

Kubernetes 中 Pod 的生命周期是短暂的，Pod 重启或重新调度后，容器内的数据会丢失。为了实现数据持久化，Kubernetes 提供了一套完整的存储抽象体系——PV（PersistentVolume）、PVC（PersistentVolumeClaim）和 StorageClass，将存储资源的"提供"与"消费"彻底解耦。本章从核心概念入手，逐步深入到 Local PV、local-path-provisioner、FlexVolume 和 CSI 等存储插件机制。

1. PV、PVC、StorageClass 概念和区别

为什么需要这套抽象？

在 Kubernetes 中，Pod 本身是无状态的，容器内的文件系统是临时的。如果希望 Pod 在重新调度（例如节点故障或升级）后依然能访问之前的数据，就必须使用具备持久化能力的网络存储。但问题在于：底层存储类型多种多样（NFS、iSCSI、Ceph、云盘等），如果让应用开发者直接配置这些存储细节，会带来巨大的耦合和维护负担。

Kubernetes 通过 PV/PVC/StorageClass 这套资源抽象，实现了"接口与实现的分离"——让开发者只关心"我需要什么"，让运维只关心"我有什么"。

三者关系概览

PersistentVolume（PV）

PV 是集群级别的存储资源，代表集群中一块已经存在的、具体的存储空间。它由集群管理员预先配置，包含了存储的全部细节：

创建静态 PV 示例（NFS）：

yamlapiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-10gi
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    server: 192.168.1.100
    path: /data/nfs/share

PV 有以下几个生命周期状态：

PersistentVolumeClaim（PVC）

PVC 是命名空间级别的存储"申请单"，由应用开发者创建，描述应用需要什么样的存储，而不关心这些存储具体从哪里来。PVC 的定义只包含"我需要什么"：

yamlapiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: slow

PVC 与 PV 的绑定规则：

Kubernetes 控制平面的 persistent-volume-controller 持续监听并匹配满足 PVC 要求的 PV：

1. 容量匹配：PV 的 capacity.storage 必须 ≥ PVC 的 requests.storage
2. 访问模式匹配：PV 的 accessModes 必须包含 PVC 声明的访问模式
3. StorageClass 匹配：
   • PVC 指定了 storageClassName: "slow" → 只绑定 storageClassName: slow 的 PV
   • PVC 指定了 storageClassName: "" → 只绑定没有设置 storageClassName 的 PV（静态 PV）
   • PVC 未指定 storageClassName → 如果有默认 StorageClass，则使用默认 StorageClass 动态创建 PV
4. LabelSelector（可选）：通过标签精确匹配
5. VolumeMode：PV 和 PVC 的 volumeMode 必须一致

绑定是一对一的：一个 PVC 只能绑定一个 PV，一个 PV 也只能被一个 PVC 绑定。绑定后，Pod 即可通过 PVC 名称挂载存储卷。

Pod 中使用 PVC：

yamlapiVersion: v1
kind: Pod
metadata:
  name: nginx-with-pvc
spec:
  containers:
    - name: nginx
      image: nginx:alpine
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: my-app-pvc

访问模式（Access Modes）

不同存储后端支持的访问模式不同。例如块存储（EBS、云盘）通常只支持 RWO，NFS/CephFS 支持 RWX。

StorageClass（存储类）

StorageClass 是动态创建 PV 的"模板"。手动管理成百上千个 PV 是运维灾难，StorageClass 定义了一个"存储模板"，告诉 Kubernetes 如何按需自动创建 PV。当用户创建指定了 storageClassName 的 PVC 时，如果找不到匹配的静态 PV，对应的 Provisioner 就会自动创建 PV 和底层存储。

StorageClass YAML 示例：

yamlapiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"  # 设为默认
provisioner: ebs.csi.aws.com        # 指定使用哪个 Provisioner
parameters:                          # 传递给 Provisioner 的参数
  type: gp3
  iops: "4000"
  throughput: "200"
  encrypted: "true"
reclaimPolicy: Delete                # 回收策略
volumeBindingMode: WaitForFirstConsumer  # 卷绑定模式
allowVolumeExpansion: true           # 允许在线扩容
mountOptions:                        # 挂载选项
  - debug

StorageClass 核心字段说明：

默认 StorageClass：

集群管理员可以将某个 StorageClass 标记为默认：

bashkubectl patch storageclass fast-ssd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

当 PVC 没有指定 storageClassName 时，会自动使用默认 StorageClass 动态创建 PV。如果集群中多个 StorageClass 都标记为默认，Kubernetes 使用最新创建的那个。

静态供应 vs 动态供应

动态供应 PVC 示例：

yamlapiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd    # 指定 StorageClass
  resources:
    requests:
      storage: 20Gi

创建此 PVC 后，fast-ssd StorageClass 对应的 Provisioner 会自动创建 20Gi 的 PV 和底层存储，并与 PVC 绑定。

回收策略（Reclaim Policy）

卷绑定模式（VolumeBindingMode）

这个参数对云环境至关重要，直接影响 Pod 能否成功挂载卷。

Immediate（默认）：

PVC 创建后立即创建 PV 和底层存储。问题是：在云环境中，块存储（如 AWS EBS）是可用区（AZ）级别的资源。如果 Pod 最终被调度到与存储卷不同的可用区，Pod 将永远无法挂载该卷。

WaitForFirstConsumer（推荐）：

延迟 PV 的创建，直到第一个使用该 PVC 的 Pod 被成功调度到某个节点上。此时 Provisioner 会在 Pod 所在可用区创建卷，确保亲和性。

yamlapiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: zonal-storage
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer  # 关键配置

最佳实践

1. 生产环境使用动态供应：配置合适的 StorageClass，避免手动管理 PV
2. 重要数据使用 Retain 策略：防止误删 PVC 导致数据丢失
3. 云环境启用 WaitForFirstConsumer：解决跨可用区挂载问题
4. 合理选择访问模式：大部分场景用 RWO 即可，避免引入不必要的复杂度
5. 监控存储使用情况：PVC 的 storage 字段是限制值，实际使用量需要监控底层存储

2. Local PV

概念与原理

Local Persistent Volume（Local PV）表示挂载在节点本地的存储设备，如本地磁盘、SSD、NVMe 等。与 hostPath 不同，Local PV 通过 PV/PVC 机制管理，具有持久化能力，且 Kubernetes 调度器会感知 Local PV 的节点亲和性。

Local PV 的核心特性是 nodeAffinity——PV 必须声明自己位于哪个节点上，调度器会确保使用该 PV 的 Pod 被调度到该节点。

为什么需要 Local PV？

Local PV vs hostPath

Local PV 的 StorageClass 定义

Local PV 不支持自动制备（没有内置 Provisioner），需要手动创建 PV。但 StorageClass 仍然需要定义，用于设置 volumeBindingMode: WaitForFirstConsumer：

yamlapiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner  # 表示不支持自动制备
volumeBindingMode: WaitForFirstConsumer    # 延迟绑定，等待 Pod 调度

创建 Local PV

yamlapiVersion: v1
kind: PersistentVolume
metadata:
  name: local-pv-ssd-node1
spec:
  capacity:
    storage: 100Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - node1

关键点：

• local.path 指定节点上的本地路径
• nodeAffinity 必须指定，确保 Pod 被调度到该节点
• storageClassName 与 StorageClass 定义一致

Local PV 的限制与风险

适用场景：Kafka、Elasticsearch、Cassandra 等应用层已实现数据副本的分布式系统，它们可以利用本地高性能存储，同时通过应用层副本保证数据安全。

3. local-path-provisioner

什么是 local-path-provisioner

local-path-provisioner 是 Rancher 开源的一个轻量级存储 Provisioner，它为 Kubernetes 集群提供了一种利用节点本地存储自动创建 PV 的能力。K3s 默认自带此组件。

它本质上是一个自动管理 hostPath 的控制器，让用户像使用 NFS/Longhorn 那样通过 PVC 申请存储，但数据实际存储在节点本地磁盘上。

工作原理

安装与部署

K3s 默认自带，无需额外安装。对于标准 Kubernetes 集群：

bashkubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml

安装后会自动创建：

• 命名空间 local-path-storage
• StorageClass local-path
• Deployment local-path-provisioner
• ConfigMap local-path-config

默认 StorageClass

yamlapiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-path
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: rancher.io/local-path
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete

使用方式

yaml# PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: local-path-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-path
  resources:
    requests:
      storage: 2Gi

---
# Pod
apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
    - name: volume-test
      image: nginx:stable-alpine
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: local-path-pvc

配置自定义路径

默认存储路径为 /opt/local-path-provisioner/。通过 ConfigMap 可自定义每个节点的路径：

yamlapiVersion: v1
kind: ConfigMap
metadata:
  name: local-path-config
  namespace: local-path-storage
data:
  config.json: |
    {
      "nodePathMap": [
        {
          "node": "DEFAULT_PATH_FOR_NON_LISTED_NODES",
          "paths": ["/opt/local-path-provisioner"]
        },
        {
          "node": "node-with-ssd",
          "paths": ["/data/ssd", "/data/ssd2"]
        }
      ]
    }

多 StorageClass 配置

local-path-provisioner 支持定义多个 StorageClass，使用不同的节点路径：

yamlapiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ssd-local-path
provisioner: rancher.io/local-path
parameters:
  nodePath: /data/ssd
  pathPattern: "{{ .PVC.Namespace }}/{{ .PVC.Name }}"
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete

优缺点

4. StorageClass 如何与 Provisioner 关联

关联机制

StorageClass 与 Provisioner 的关联是通过 provisioner 字段完成的，这是一个名称匹配机制：

yamlapiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-sc
provisioner: rancher.io/local-path    # 这个名称必须与运行中的 Provisioner 一致

完整的关联流程

常用 Provisioner 名称对照

树内 Provisioner vs CSI Provisioner

Kubernetes 早期版本的存储插件是"树内（in-tree）"的，即编译在 Kubernetes 核心代码中。这种方式存在严重问题：

• 存储插件与 Kubernetes 版本强绑定
• 新增存储插件需要修改 Kubernetes 核心代码
• 插件 bug 可能影响整个集群稳定性

因此社区正在将所有树内卷插件迁移到 CSI（Container Storage Interface）驱动。CSI 是树外（out-of-tree）的，独立于 Kubernetes 版本发布。

关键注意事项

1. provisioner 名称必须精确匹配：大小写敏感，不能有空格
2. 一个 Provisioner 可以对应多个 StorageClass：通过不同的 parameters 区分存储类型
3. Provisioner 必须提前部署：在创建 StorageClass 之前，Provisioner 必须已经在集群中运行
4. parameters 由 Provisioner 定义：不同 Provisioner 支持的参数完全不同，需要查阅对应文档

5. FlexVolume

什么是 FlexVolume

FlexVolume 是 Kubernetes v1.8+ 引入的一种存储插件扩展方式，允许用户编写外部可执行文件来实现自定义存储插件，而无需修改 Kubernetes 核心代码。

工作原理

FlexVolume 基于可执行文件接口：Kubernetes 在需要执行 Attach/Detach/Mount/Unmount 等操作时，调用预先放置在指定目录下的可执行文件（如 shell 脚本或二进制文件），并传递 JSON 格式的参数。

插件目录结构

text/usr/libexec/kubernetes/kubelet-plugins/volume/exec/
└── <vendor~driver>/
    └── <driver>          ← 可执行文件

例如 NFS 插件：

text/usr/libexec/kubernetes/kubelet-plugins/volume/exec/
└── k8s~nfs/
    └── nfs

FlexVolume 接口

FlexVolume 插件需要实现以下操作（根据存储类型，部分可选）：

NFS FlexVolume 示例

插件脚本（nfs）：

bash#!/bin/bash

operation=$1

case "$operation" in
  init)
    # 初始化，返回插件能力
    echo '{"status": "Success", "capabilities": {"attach": false}}'
    ;;
  mount)
    # 参数：mount <mount-dir> <json-params>
    mount_dir=$2
    json_params=$3

    # 解析 JSON 参数
    server=$(echo "$json_params" | jq -r '.server')
    share=$(echo "$json_params" | jq -r '.share')

    mount -t nfs "${server}:${share}" "${mount_dir}"
    if [ $? -eq 0 ]; then
      echo '{"status": "Success"}'
    else
      echo '{"status": "Failure", "message": "Failed to mount NFS"}'
    fi
    ;;
  unmount)
    mount_dir=$2
    umount "${mount_dir}"
    if [ $? -eq 0 ]; then
      echo '{"status": "Success"}'
    else
      echo '{"status": "Failure", "message": "Failed to unmount"}'
    fi
    ;;
  *)
    echo '{"status": "Not supported"}'
    ;;
esac

PV 定义（使用 FlexVolume）：

yamlapiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-flex-nfs
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  flexVolume:
    driver: k8s/nfs        # 对应 vendor~driver = k8s~nfs
    options:                # 传递给 mount 操作的 JSON 参数
      server: "192.168.1.100"
      share: "/data/nfs"

FlexVolume 的局限性

迁移建议

FlexVolume 已被 Kubernetes 社区标记为 deprecated。如果你仍在使用 FlexVolume 插件，建议尽快迁移到对应的 CSI 驱动。大多数主流存储厂商都提供了 CSI 驱动替代方案。

6. CSI（Container Storage Interface）

什么是 CSI

CSI（Container Storage Interface）是 Kubernetes 存储扩展的现代标准，它将存储插件的开发从 Kubernetes 核心代码中完全解耦出来。CSI 通过 gRPC 协议定义了一套标准化的接口，存储厂商只需实现这些接口，就能让 Kubernetes 无缝使用其存储系统。

CSI 的设计目标是：

• 标准化：一套接口适配所有存储系统
• 解耦：存储插件独立于 Kubernetes 版本发布
• 容器化：插件以容器方式部署，无需修改宿主机

⚠️ CSI 三层结构：哪个自带？哪个要安装？

这是最容易混淆的地方。CSI 不是"一个东西"，而是三层不同的组件：

打个比方：CSI 规范相当于"USB 接口标准"（K8s 内置），Sidecar 相当于"USB 控制器芯片驱动"（官方提供），CSI Driver 相当于"U 盘 / 移动硬盘"（存储厂商提供）。没有 USB 标准就无法通信，没有芯片驱动就认不出设备，没有 U 盘就没有实际存储。

如果不安装 CSI 驱动，K8s 怎么实现存储？

不是所有存储都需要 CSI。Kubernetes 自带一套"树内（in-tree）存储插件"，无需安装任何 CSI 驱动即可使用：

方式一：直接用树内卷类型（最简单，无需任何插件）

直接在 Pod 中声明，不需要创建 PV/PVC：

yamlapiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      emptyDir: {}          # ← 树内插件，K8s 自带，不需要任何安装

常用树内卷类型（K8s 自带，零安装）：

方式二：静态 PV + 树内存储类型

手动创建 PV，不依赖任何 StorageClass / Provisioner：

yaml# 1. 管理员手动创建 PV（使用树内 NFS 插件）
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-static-nfs
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:                          # ← 树内 NFS 插件，K8s 自带
    server: 192.168.1.100
    path: /data/nfs

---
# 2. 用户创建 PVC 绑定此 PV
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  volumeName: pv-static-nfs     # 直接指定 PV 名称

---
# 3. Pod 使用 PVC
apiVersion: v1
kind: Pod
metadata:
  name: nginx-nfs
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: my-pvc

这种方式的特点：全程不需要任何 CSI 驱动、不需要 StorageClass、不需要 Provisioner。缺点是管理员需要手动创建每一个 PV。

什么场景必须安装 CSI 驱动？

组件关系总结

一句话总结：

• Sidecar 是"翻译官"——监听 K8s API 事件，翻译成 gRPC 调用传给 Driver
• CSI Driver 是"干活的"——收到 gRPC 调用后，去实际操作后端存储系统（调用云厂商 API 创建磁盘等）
• K8s 内置的 CSI 规范是"通信协议"——定义了 Sidecar 和 Driver 之间怎么说话

CSI 架构

CSI 三大 gRPC 服务

CSI 插件通过 gRPC 对外提供三个服务，每个服务定义了不同的接口：

1. CSI Identity Service（身份服务）

提供插件的基本信息和能力声明：

protobufservice Identity {
  rpc GetPluginInfo(GetPluginInfoRequest) returns (GetPluginInfoResponse) {}      // 返回插件名称、版本
  rpc GetPluginCapabilities(GetPluginCapabilitiesRequest) returns (GetPluginCapabilitiesResponse) {}  // 声明插件能力
  rpc Probe(ProbeRequest) returns (ProbeResponse) {}                               // 健康检查
}

2. CSI Controller Service（控制器服务）

运行在 Master 节点（StatefulSet），处理集群级别的卷管理操作：

3. CSI Node Service（节点服务）

运行在每个 Worker 节点（DaemonSet），处理节点级别的卷操作：

Sidecar 容器

CSI 驱动的部署依赖 Kubernetes 社区维护的 Sidecar 容器，它们负责监听 Kubernetes API 并触发 CSI 接口调用：

CSI 卷的完整生命周期

为什么 Mount 阶段分为 NodeStageVolume 和 NodePublishVolume？

这是 CSI 设计中的一个重要细节：

• NodeStageVolume：将块设备格式化（如果需要）并挂载到全局 Staging 路径。这个路径是节点级别的，所有使用该卷的 Pod 共享。
• NodePublishVolume：将 Staging 路径 bind-mount 到 Pod 特定的目录。每个 Pod 有独立的挂载点。

这种设计的好处是：如果多个 Pod 使用同一个卷，格式化操作只执行一次，后续 Pod 只需要做 bind-mount，性能更好。

部署 CSI 驱动

CSI 驱动部署通常包含两个部分：

1. Controller 插件（StatefulSet）：

yamlapiVersion: apps/v1
kind: StatefulSet
metadata:
  name: csi-controller
  namespace: kube-system
spec:
  serviceName: csi-controller
  replicas: 1
  selector:
    matchLabels:
      app: csi-controller
  template:
    spec:
      serviceAccountName: csi-controller-sa
      containers:
        # Sidecar 容器
        - name: external-provisioner
          image: registry.k8s.io/sig-storage/csi-provisioner:v3.6.0
          args:
            - "--csi-address=/csi/csi.sock"
          volumeMounts:
            - name: socket-dir
              mountPath: /csi
        - name: external-attacher
          image: registry.k8s.io/sig-storage/csi-attacher:v4.4.0
          args:
            - "--csi-address=/csi/csi.sock"
          volumeMounts:
            - name: socket-dir
              mountPath: /csi
        # CSI 驱动容器
        - name: my-csi-driver
          image: my-registry/csi-driver:v1.0.0
          args:
            - "--endpoint=unix:///csi/csi.sock"
          volumeMounts:
            - name: socket-dir
              mountPath: /csi
      volumes:
        - name: socket-dir
          emptyDir: {}

2. Node 插件（DaemonSet）：

yamlapiVersion: apps/v1
kind: DaemonSet
metadata:
  name: csi-node
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: csi-node
  template:
    spec:
      containers:
        - name: node-driver-registrar
          image: registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.9.0
          args:
            - "--csi-address=/csi/csi.sock"
            - "--kubelet-registration-path=/var/lib/kubelet/plugins/csi.example.com/csi.sock"
          volumeMounts:
            - name: plugin-dir
              mountPath: /csi
            - name: registration-dir
              mountPath: /registration
        - name: my-csi-driver
          image: my-registry/csi-driver:v1.0.0
          args:
            - "--endpoint=unix:///csi/csi.sock"
          securityContext:
            privileged: true
          volumeMounts:
            - name: plugin-dir
              mountPath: /csi
            - name: pods-mount-dir
              mountPath: /var/lib/kubelet/pods
              mountPropagation: Bidirectional
      volumes:
        - name: plugin-dir
          hostPath:
            path: /var/lib/kubelet/plugins/csi.example.com
            type: DirectoryOrCreate
        - name: registration-dir
          hostPath:
            path: /var/lib/kubelet/plugins_registry
            type: Directory
        - name: pods-mount-dir
          hostPath:
            path: /var/lib/kubelet/pods
            type: Directory

创建 CSIDriver 对象

部署 CSI 驱动后，需要创建 CSIDriver 对象向 Kubernetes 注册：

yamlapiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: csi.example.com
spec:
  attachRequired: true          # 是否需要 Attach 操作（块存储需要，NFS 通常不需要）
  podInfoOnMount: true          # 挂载时是否传递 Pod 信息
  volumeLifecycleModes:
    - Persistent                # 支持持久卷
    - Ephemeral                 # 支持临时卷
  fsGroupPolicy: File           # 文件系统组策略
  requiresRepublish: false      # 是否需要在 Pod 重启时重新发布卷
  storageCapacity: true         # 是否支持存储容量感知调度

创建 StorageClass 使用 CSI 驱动

yamlapiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-fast-ssd
provisioner: csi.example.com             # 对应 CSIDriver 的 name
parameters:
  type: ssd
  fsType: ext4
  iops: "5000"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

常用 CSI 驱动列表

FlexVolume vs CSI 对比

树内插件迁移到 CSI

Kubernetes 社区正在将树内（in-tree）存储插件逐步迁移到 CSI 驱动。迁移时间线：

迁移步骤：

1. 安装对应的 CSI 驱动
2. 创建使用 CSI Provisioner 的新 StorageClass
3. 将 PVC 的 storageClassName 切换到新 StorageClass
4. 验证应用正常运行
5. 删除旧的树内 StorageClass 和 PV

7. UCloud CSI 实战解析

前面介绍了 CSI 的通用架构和原理，本节以 UCloud UK8s 集群为例，通过真实的 Pod 和配置，解析 CSI 在生产环境中是如何工作的。

集群 CSI 组件概览

UCloud UK8s 集群默认部署了两套 CSI Driver，分别对应两种存储产品：

映射到 CSI 三层结构：

Controller Pod：Sidecar 与 Driver 的 Socket 通信

在 csi-udisk-controller-0 中，4 个容器通过共享的 emptyDir 卷中的 UNIX Socket 通信：

关键启动参数：

Node Pod：Driver 注册到 kubelet 的机制

每个 Worker 节点运行一个 CSI Node Pod（DaemonSet），其中 node-registrar 负责将 CSI Driver 注册到 kubelet：

在 Master 节点上，/var/lib/kubelet/plugins/ 目录为空（因为 Node Pod 不运行在 Master 上），但 /var/lib/kubelet/plugins_registry/ 中能看到注册 socket：

bash# Master 节点上查看
ls /var/lib/kubelet/plugins_registry/
# udisk.csi.ucloud.cn-reg.sock  ufile.csi.ucloud.cn-reg.sock

# Worker 节点上，还能看到实际的 driver socket
ls /var/lib/kubelet/plugins/
# udisk.csi.ucloud.cn/  ufile.csi.ucloud.cn/

StorageClass 配置：一个 Provisioner 对应多个 SC

集群中有 3 个 StorageClass 使用同一个 provisioner udisk.csi.ucloud.cn，通过 parameters.type 区分磁盘规格：

以 ssd-csi-udisk 为例，完整 YAML：

yamlallowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ssd-csi-udisk
parameters:
  fsType: ext4           # 文件系统类型
  type: ssd              # 磁盘类型 ← 这是区分的关键
  udataArkMode: "no"     # 数据方舟（UCloud 备份功能）
provisioner: udisk.csi.ucloud.cn
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

三个 StorageClass 的唯一差异就是 type 参数——csi-udisk driver 收到 CreateVolume gRPC 调用时，会根据 type 值调用不同的 UCloud API 创建不同规格的云盘。

UCloud CSI 完整创建流程

以创建一个使用 SSD 云盘的 Pod 为例，完整数据流如下：

镜像版本信息

与通用 CSI 架构的对照

8. 总结

Kubernetes 存储体系的核心设计思想是接口与实现的分离：

• PV 代表存储的"实现"（具体的存储资源）
• PVC 代表存储的"接口"（用户的需求声明）
• StorageClass 是动态创建的"模板"（自动化 PV 创建）
• Provisioner 是具体的"执行者"（实际创建存储卷的组件）

在存储插件选择上：

• 开发/测试环境：local-path-provisioner 是最简单实用的选择
• 生产环境：使用 CSI 驱动，根据存储类型选择（云盘、NFS、Ceph 等）
• 高性能场景：Local PV 提供最低延迟，但需应用层保证数据副本
• FlexVolume：已过时，不建议新项目使用，应迁移到 CSI