---
tags: [k8s, storage, pv, pvc, statefulset, devops]
create time: 2026-07-07 15:48
---

# Kubernetes 存储 — PV、PVC 与 StatefulSet

## 概述

容器的本质是短暂的（ephemeral）：Pod 被删除后，其内部所有文件随之消散。这对无状态服务无关紧要，但对数据库、消息队列等有状态应用来说是致命的。Kubernetes 通过分层存储抽象 —— **Volume → PersistentVolume（PV）→ PersistentVolumeClaim（PVC）→ StorageClass** —— 将"存储供给"与"存储消费"解耦，让开发者无需关心底层基础设施，只需声明"我需要多大、什么访问模式的存储"，即可自动获得持久化能力。配合 StatefulSet，K8s 还为有状态应用提供了稳定的网络标识和有序的生命周期管理。

## 卷（Volume）基础

Volume 是 K8s 最早引入的存储概念，与 Pod 同生命周期（除非是持久卷类型）。它定义在 Pod spec 中，可被同一 Pod 内的多个容器共享。

### 常见卷类型

| 卷类型 | 生命周期 | 典型用途 | 是否持久 |
|--------|----------|----------|----------|
| `emptyDir` | Pod 存续期间 | 容器间共享临时文件、缓存 | 否 |
| `hostPath` | 节点存续期间 | 访问宿主机文件（如 Docker socket） | 节点级持久 |
| `nfs` | 独立于 Pod | 多节点共享存储 | 是 |
| `configMap` / `secret` | Pod 存续期间 | 注入配置和敏感信息 | 否 |
| `persistentVolumeClaim` | 独立于 Pod | 绑定 PV，正式的持久化方案 | 是 |

### emptyDir 示例

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: shared-data
spec:
  containers:
    - name: writer
      image: busybox
      command: ["sh", "-c", "echo hello > /data/msg && sleep 3600"]
      volumeMounts:
        - name: cache
          mountPath: /data
    - name: reader
      image: busybox
      command: ["sh", "-c", "cat /data/msg && sleep 3600"]
      volumeMounts:
        - name: cache
          mountPath: /data
  volumes:
    - name: cache
      emptyDir: {}
```

> [!tip] emptyDir 的 `medium: Memory` 配置可将其挂载为 tmpfs（RAM 磁盘），适用于对 I/O 延迟极敏感的场景，但会计入容器内存用量。

### hostPath 注意事项

hostPath 直接暴露宿主机目录，存在安全风险。生产环境应优先使用 PVC。如果必须使用，建议设置 `type` 字段限制行为：

```yaml
volumes:
  - name: docker-sock
    hostPath:
      path: /var/run/docker.sock
      type: Socket  # 仅允许已存在的 socket 文件
```

hostPath 的 `type` 可选值：`DirectoryOrCreate`、`Directory`、`FileOrCreate`、`File`、`Socket`、`CharDevice`、`BlockDevice`。

## 持久卷（PersistentVolume）

PersistentVolume（PV）是集群级别的存储资源，由管理员预先创建或由 StorageClass 动态供给。它与 Pod 完全解耦 —— Pod 删除后 PV 仍然存在。

### PV 详解

```yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-data
spec:
  capacity:
    storage: 10Gi           # 存储容量
  accessModes:
    - ReadWriteMany         # 访问模式
  persistentVolumeReclaimPolicy: Retain  # 回收策略
  storageClassName: slow    # 存储类名称
  nfs:
    server: 192.168.1.100
    path: /exports/data
```

关键字段说明：

| 字段 | 说明 |
|------|------|
| `capacity.storage` | PV 的存储容量，只能声明一种资源（目前仅支持 storage） |
| `accessModes` | 定义卷的挂载方式，可声明多种，但实际只能使用一种 |
| `persistentVolumeReclaimPolicy` | PVC 释放后 PV 的处理策略：Retain / Delete / Recycle |
| `storageClassName` | 关联的 StorageClass 名称，为空字符串表示不关联任何类 |
| `volumeMode` | `Filesystem`（默认）或 `Block`（原始块设备） |
| `mountOptions` | 挂载选项，如 `["hard", "nfsvers=4.1"]` |

> [!info] PV 的状态包括 `Available`（未绑定）、`Bound`（已绑定到 PVC）、`Released`（PVC 已删除但 PV 未回收）、`Failed`（自动回收失败）。

### 回收策略（Reclaim Policy）

当 PVC 被删除后，PV 的回收策略决定了其后续行为。

| 策略 | 行为 | 适用场景 |
|------|------|----------|
| **Retain** | PV 状态变为 `Released`，数据保留，需管理员手动处理 | 有保留价值的数据 |
| **Delete** | PV 及底层存储资源一并删除 | 动态供给的临时存储 |
| **Recycle** | 执行 `rm -rf /volume/*`，PV 回到 `Available`（已废弃） | 仅兼容简单存储后端 |

```mermaid
stateDiagram-v2
    [*] --> Available: PV 创建
    Available --> Bound: PVC 绑定
    Bound --> Released: PVC 删除

    Released --> Available: Recycle (rm -rf)
    Released --> [*]: Delete (删除底层存储)
    Released --> Released: Retain (等待手动处理)

    state "管理员手动操作" as manual
    Released --> manual: 需人工介入
    manual --> Available: 修复后重新上线
    manual --> [*]: 彻底删除
```

> [!warning] Recycle 策略已被废弃，且仅对 NFS 和 hostPath 有效。生产环境应优先使用动态供给 + Delete 策略，或 Retain 策略配合手动运维。

### 访问模式（Access Modes）

| 模式 | 缩写 | 含义 |
|------|------|------|
| ReadWriteOnce | RWO | 单节点读写挂载 |
| ReadOnlyMany | ROX | 多节点只读挂载 |
| ReadWriteMany | RWX | 多节点读写挂载 |
| ReadWriteOncePod | RWOP | 单 Pod 读写（K8s 1.22+） |

各存储后端对访问模式的支持情况：

| 存储后端 | RWO | ROX | RWX | RWOP |
|----------|-----|-----|-----|------|
| 本地磁盘 (local) | 支持 | - | - | 支持 |
| AWS EBS | 支持 | - | - | 支持 |
| GCE PD | 支持 | 支持 | - | 支持 |
| Azure Disk | 支持 | - | - | 支持 |
| Azure File | 支持 | 支持 | 支持 | - |
| Ceph RBD | 支持 | 支持 | - | - |
| CephFS | 支持 | 支持 | 支持 | - |
| NFS | 支持 | 支持 | 支持 | - |
| Longhorn | 支持 | 支持 | 支持 | - |

> [!tip] 为什么不是所有存储都支持 RWX？因为多节点同时写入需要分布式文件系统级别的并发控制（如分布式锁、一致性协议）。块存储（EBS、PD）天然不支持多写，必须通过 NFS/文件系统层封装才能实现 RWX。

## 持久卷声明（PersistentVolumeClaim）

PVC 是用户对存储资源的"请求"。用户不直接创建或管理 PV，而是通过 PVC 声明需求（容量、访问模式、存储类），K8s 负责将合适的 PV 绑定到 PVC。

```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: fast-ssd
```

### PVC 绑定机制

PVC 与 PV 的绑定有两种模式：

#### 静态供给（Static Provisioning）

管理员手动创建 PV 资源，用户创建 PVC 后，K8s 控制面中的 PV controller 根据容量、访问模式、存储类等条件进行匹配。

#### 动态供给（Dynamic Provisioning）

用户创建 PVC 后，若集群中没有匹配的 PV，且 PVC 指定了 StorageClass，K8s 会调用对应的 provisioner 自动创建 PV 并完成绑定。这是生产环境中最常用的方式。

```mermaid
flowchart TD
    A[用户创建 PVC] --> B{是否有匹配的 Available PV?}
    B -->|是| C[绑定 PV 到 PVC]
    B -->|否| D{PVC 指定了 StorageClass?}
    D -->|否| E[PVC 持续 Pending]
    D -->|是| F[StorageClass Provisioner 创建 PV]
    F --> C
    C --> G[Pod 挂载 PVC 使用]

    style E fill:#f96,stroke:#333
    style G fill:#6f9,stroke:#333
```

绑定匹配规则：
1. PV 与 PVC 的 `storageClassName` 必须一致
2. PV 的 `accessModes` 必须包含 PVC 请求的模式
3. PV 的 `capacity.storage` 必须 >= PVC 请求的容量
4. PV 的 `volumeMode` 必须匹配
5. 若存在多个匹配 PV，优先选择容量最小的满足者（最小匹配原则）
6. 可通过标签选择器（`selector`）进一步筛选

> [!info] 一对一绑定：一个 PV 只能绑定一个 PVC，一个 PVC 也只能绑定一个 PV。绑定后即使 PV 的标签被修改，绑定关系也不会解除。

### StorageClass

StorageClass 定义了存储的"类别"，是动态供给的核心。它告诉 K8s 使用哪个 provisioner、以什么参数创建存储。

```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs  # 存储驱动
parameters:
  type: gp3                          # 传递给 provisioner 的参数
  fsType: ext4
  iopsPerGB: "50"
reclaimPolicy: Delete                # PV 回收策略
volumeBindingMode: WaitForFirstConsumer  # 绑定时机
allowVolumeExpansion: true           # 允许扩容
mountOptions:
  - debug
```

关键字段详解：

| 字段 | 说明 | 常见值 |
|------|------|--------|
| `provisioner` | 存储驱动标识 | `kubernetes.io/aws-ebs`、`rancher.io/local-path`、`csi.hetzner.cloud` 等 |
| `parameters` | 传递给 provisioner 的键值对，不同驱动参数不同 | EBS: `type`/`fsType`；Ceph: `pool`/`clusterID` |
| `reclaimPolicy` | 动态创建的 PV 的回收策略，默认 `Delete` | `Retain`、`Delete` |
| `volumeBindingMode` | PV 创建和绑定的时机 | `Immediate`（默认）、`WaitForFirstConsumer` |
| `allowVolumeExpansion` | 是否允许 PVC 扩容，默认 `false` | `true`、`false` |
| `mountOptions` | 动态创建的 PV 的挂载选项 | NFS: `["hard","nfsvers=4.1"]` |

> [!warning] `volumeBindingMode: WaitForFirstConsumer` 的重要性：默认的 `Immediate` 模式会在 PVC 创建时立即绑定/创建 PV，这可能导致 PV 创建在与 Pod 不同的可用区（尤其在多可用区集群中），最终 Pod 调度失败。`WaitForFirstConsumer` 会延迟到 Pod 调度时才创建 PV，确保存储与计算在同一拓扑域。

```mermaid
sequenceDiagram
    participant User as 用户
    participant API as API Server
    participant SC as StorageClass
    participant PV Controller
    participant Provisioner

    Note over User,Provisioner: Immediate 模式
    User->>API: 创建 PVC
    API->>PV Controller: 协调 PVC
    PV Controller->>Provisioner: 创建 PV
    Provisioner-->>PV Controller: PV Ready
    PV Controller->>API: 绑定 PV ↔ PVC

    Note over User,Provisioner: WaitForFirstConsumer 模式
    User->>API: 创建 PVC (Pending)
    User->>API: 创建 Pod
    API->>PV Controller: Pod 调度完成，触发绑定
    PV Controller->>Provisioner: 在 Pod 所在节点/可用区创建 PV
    Provisioner-->>PV Controller: PV Ready
    PV Controller->>API: 绑定 PV ↔ PVC
```

## StatefulSet

StatefulSet 是 K8s 为有状态应用设计的工作负载控制器，解决了 Deployment 无法满足的三个核心需求：

1. **稳定的网络标识**：Pod 名称固定（`pod-0`、`pod-1`），通过 Headless Service 提供 DNS 记录（`pod-0.service-name.namespace.svc.cluster.local`）
2. **稳定的持久存储**：每个 Pod 拥有独立的 PVC，Pod 重建后 PVC 不变
3. **有序的部署/扩缩/删除**：Pod 按序号顺序操作，前一个就绪后才启动下一个

### StatefulSet vs Deployment

| 特性 | Deployment | StatefulSet |
|------|-----------|-------------|
| Pod 名称 | 随机后缀 | 有序编号（`-0`、`-1`、`-2`） |
| 部署顺序 | 并行 | 顺序（前一个 Ready 后才启动下一个） |
| 删除顺序 | 并行 | 逆序 |
| 网络标识 | 不稳定 | 稳定，配合 Headless Service |
| 存储 | 共享 PVC 或无存储 | 每个 Pod 独立 PVC（通过 `volumeClaimTemplates`） |
| 缩容 | 随机删除 | 从最大序号开始删除 |

### volumeClaimTemplates

`volumeClaimTemplates` 是 StatefulSet 的核心特性 —— 它会为每个 Pod 自动创建独立的 PVC。

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql          # 必须关联 Headless Service
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: mysql:8.0
          volumeMounts:
            - name: data
              mountPath: /var/lib/mysql
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 20Gi
```

上例中，K8s 会自动创建三个 PVC：`data-mysql-0`、`data-mysql-1`、`data-mysql-2`，每个绑定独立的 PV。

> [!info] StatefulSet 缩容时，PVC 不会被删除。这意味着缩容后再扩容，新 Pod 会重新挂载原来的 PVC，数据不丢失。这是 StatefulSet 最重要的特性之一。

## CSI（Container Storage Interface）

CSI 是 K8s 存储插件的标准化接口规范（自 K8s 1.13 GA），取代了早期的 in-tree volume plugin 方式。

### 为什么需要 CSI

早期 K8s 的存储驱动代码直接存在于 K8s 主仓库（in-tree），导致：
- 存储供应商必须将代码合入 K8s 仓库，发布周期受限于 K8s
- K8s 仓库臃肿，维护负担重
- 驱动 bug 可能影响 K8s 核心组件稳定性

CSI 将存储驱动移出 K8s 核心（out-of-tree），通过 gRPC 接口标准化通信。

### CSI 架构

```mermaid
graph TD
    subgraph "Kubernetes 组件"
        AK[API Server]
        KC[kube-controller-manager]
        KM[kubelet]
    end

    subgraph "CSI 组件（集群级别）"
        CP[CSI Controller Plugin]
        CS[CSI Driver 注册]
    end

    subgraph "CSI 组件（节点级别）"
        NP[CSI Node Plugin]
    end

    subgraph "存储后端"
        S[Cloud Provider / SAN / NFS]
    end

    AK --> KC
    KC -->|创建/删除/扩容| CP
    CP --> S
    KM -->|挂载/卸载| NP
    NP --> S
    CS -.->|注册| AK
```

CSI 的三个核心组件：
- **CSI Controller Plugin**：集群级别，负责卷的创建、删除、快照、扩容等控制面操作
- **CSI Node Plugin**：节点级别，负责卷的挂载（NodePublishVolume）、卸载（NodeUnpublishVolume）等数据面操作
- **CSIDriver 对象**：在 K8s 中注册驱动，声明能力（如 `attachRequired`、`podInfoOnMount`）

### 常见 CSI 驱动

| 存储后端 | CSI 驱动名称 | 说明 |
|----------|-------------|------|
| AWS EBS | `ebs.csi.aws.com` | AWS 官方，替代 in-tree aws-ebs |
| GCE PD | `pd.csi.storage.gke.io` | GCP 官方 |
| Azure Disk | `disk.csi.azure.com` | Azure 官方 |
| Ceph RBD | `rbd.csi.ceph.com` | Ceph 官方 |
| Longhorn | `driver.longhorn.io` | Rancher 开源分布式存储 |
| OpenEBS | `openebs.io/local` / `openebs.io/zfs-localpv` | 开源容器原生存储 |
| Hetzner Cloud | `csi.hetzner.cloud` | Hetzner 云盘 |
| 本地路径 | `rancher.io/local-path` | Local Path Provisioner，开发测试常用 |

### CSI Driver 部署示例

以 AWS EBS CSI Driver 为例，通常通过 Helm 安装：

```bash
helm repo add aws-ebs-csi-driver https://kubernetes-sigs.github.io/aws-ebs-csi-driver
helm install aws-ebs-csi-driver aws-ebs-csi-driver/aws-ebs-csi-driver \
  --namespace kube-system
```

安装后会在集群中创建 `ebs.csi.aws.com` CSIDriver 对象和对应的 DaemonSet（Node Plugin）+ Deployment（Controller Plugin）。

## 实战示例

以下完整示例演示如何部署一个带持久化存储的 MySQL StatefulSet。

### 1. StorageClass

```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mysql-ssd
provisioner: rancher.io/local-path       # 本地开发环境使用 local-path
reclaimPolicy: Retain                     # 数据库场景用 Retain 更安全
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
```

### 2. Headless Service

```yaml
apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  ports:
    - port: 3306
      targetPort: 3306
      name: mysql
  clusterIP: None            # Headless Service，StatefulSet 必需
  selector:
    app: mysql
```

### 3. StatefulSet

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 1               # 单节点 MySQL，生产建议配合 Operator 做主从
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: mysql:8.0
          ports:
            - containerPort: 3306
              name: mysql
          env:
            - name: MYSQL_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-secret
                  key: ROOT_PASSWORD
          volumeMounts:
            - name: mysql-data
              mountPath: /var/lib/mysql
          resources:
            requests:
              cpu: 250m
              memory: 512Mi
            limits:
              cpu: "1"
              memory: 1Gi
          readinessProbe:
            exec:
              command:
                - mysqladmin
                - ping
                - -h
                - localhost
            initialDelaySeconds: 10
            periodSeconds: 5
  volumeClaimTemplates:
    - metadata:
        name: mysql-data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: mysql-ssd
        resources:
          requests:
            storage: 10Gi
```

### 4. Secret（MySQL root 密码）

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: mysql-secret
type: Opaque
stringData:
  ROOT_PASSWORD: "MyS3cur3P@ssw0rd"
```

### 5. 客户端 Pod 测试连接

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: mysql-client
spec:
  containers:
    - name: mysql-client
      image: mysql:8.0
      command: ["sleep", "3600"]
```

进入客户端 Pod 后，使用 StatefulSet 的稳定 DNS 名称连接：

```bash
kubectl exec -it mysql-client -- bash
mysql -h mysql-0.mysql.default.svc.cluster.local -u root -p
```

> [!tip] DNS 解析规则：`<pod-name>.<headless-service-name>.<namespace>.svc.cluster.local`。`mysql-0.mysql` 即可解析，完整 FQDN 为 `mysql-0.mysql.default.svc.cluster.local`。

## 常见陷阱与最佳实践

### PVC 持续 Pending

**现象**：PVC 长时间处于 Pending 状态，Pod 无法启动。

**排查步骤**：

```bash
# 查看 PVC 事件
kubectl describe pvc <pvc-name>

# 查看是否有匹配的 PV
kubectl get pv

# 查看 StorageClass 是否存在
kubectl get storageclass
```

**常见原因**：
- 没有匹配的 Available PV（静态供给场景下）
- StorageClass 的 provisioner 未安装或配置错误
- `volumeBindingMode: WaitForFirstConsumer` 下，没有 Pod 消费该 PVC
- 底层存储配额不足或权限不足

### 动态供给配置错误

**现象**：PVC Pending，事件中显示 `waiting for first consumer to be created before binding`。

**排查**：确认 `volumeBindingMode` 设置是否符合预期。如果 Pod 已经存在但仍未绑定，检查：
- Pod 是否成功调度到节点（Pod 事件）
- CSI Node Plugin 是否在目标节点正常运行（DaemonSet Pod 状态）
- Provisioner 的参数是否正确（如 `parameters.type` 是否为合法值）

### RWX 不支持的存储类型

**现象**：PVC 声明 `ReadWriteMany` 但一直 Pending。

**原因**：块存储（EBS、GCE PD、Azure Disk）不支持 RWX。解决方案：
- 使用支持 RWX 的存储后端：NFS、CephFS、Azure File、Longhorn、OpenEBS
- 使用 ReadWriteOnce（如果应用本身不支持多写，如 MySQL 单实例）
- 引入分布式锁机制或应用层复制

### PVC 扩容

扩容需要 StorageClass 设置 `allowVolumeExpansion: true`，且 CSI 驱动支持在线扩容：

```bash
# 编辑 PVC 请求的容量
kubectl patch pvc mysql-data-mysql-0 -p '{"spec":{"resources":{"requests":{"storage":"20Gi"}}}}'

# 查看扩容进度
kubectl describe pvc mysql-data-mysql-0
```

> [!warning] PVC 扩容只能增大不能缩小。部分存储后端支持在线扩容（无需重启 Pod），部分需要 unmount 后才能扩容，具体取决于 CSI 驱动实现。

### 数据备份策略

PV 中的数据没有内置的备份机制，需要额外配置：

- **VolumeSnapshot**：K8s 1.20+ GA，通过 CSI 驱动创建卷快照
- **Velero**：开源的 K8s 备份恢复工具，支持卷快照 + 资源对象的完整备份
- **应用层备份**：对于数据库，使用 `mysqldump`、`pg_dump` 等原生工具定期备份
- **存储层快照**：利用云平台的 EBS Snapshot、Azure Snapshot 等定期快照

```yaml
# VolumeSnapshot 示例
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mysql-snapshot
spec:
  volumeSnapshotClassName: csi-aws-ebs-snapclass
  source:
    persistentVolumeClaimName: mysql-data-mysql-0
```

### 最佳实践总结

1. **始终使用 `volumeBindingMode: WaitForFirstConsumer`**，避免多可用区集群中存储与计算分离
2. **数据库场景使用 `reclaimPolicy: Retain`**，防止误删 PVC 导致数据丢失
3. **为 StatefulSet 配置 Readiness Probe**，确保 K8s 在 Pod 真正就绪后才启动下一个
4. **生产环境使用 CSI 驱动替代 in-tree plugin**，获得更好的维护性和功能支持
5. **定期备份 PV 数据**，不要依赖 K8s 的存储抽象作为唯一的持久化保障
6. **监控 PV 使用率**，设置 PVC 扩容告警，避免磁盘满导致服务中断
7. **避免使用 `hostPath`** 作为生产存储方案，除非有明确的安全和隔离措施

## 延伸阅读

- [[k8s-03-pod]] — Pod 基础与生命周期
- [[k8s-02-architecture]] — Kubernetes 整体架构