1. Kubernetes 存储概述
1.1 Kubernetes 存储发展历程
Kubernetes 存储能力从最初的“有状态工作负载基本不可用”逐步演进为“云原生存储一等公民”，其发展可划分为四个关键阶段：
| 阶段 | Kubernetes 版本 | 核心能力 | 标志性特性 |
|---|---|---|---|
| 萌芽期 | v1.0 – v1.2 | 仅支持 emptyDir、hostPath 等临时存储 | Volume 原语诞生 |
| 扩展期 | v1.3 – v1.5 | 引入 PersistentVolume / PersistentVolumeClaim 资源模型 | PV/PVC 解耦存储与计算 |
| 生态期 | v1.6 – v1.12 | StorageClass 动态供给、CSI 容器存储接口规范 | 存储插件标准化 |
| 成熟期 | v1.13+ | CSI GA、卷快照、卷克隆、卷扩展、跨 AZ 拓扑感知 | 存储成为一等资源 |
关键里程碑：Kubernetes v1.13 正式将 CSI（Container Storage Interface）标记为 GA（General Availability），标志着存储插件生态从 in-tree 走向 out-of-tree，云原生存储进入高速发展通道。
1.2 存储资源模型核心概念
Kubernetes 存储资源模型围绕“声明式存储”设计，核心抽象包括以下四个层次：
- Volume（卷）：Pod 级别的存储抽象，生命周期与 Pod 绑定，支持 emptyDir、hostPath、ConfigMap、Secret 等内置类型。
- PersistentVolume（PV）：集群级别的存储资源，由管理员预先制备或通过 StorageClass 动态供给，独立于 Pod 存在。
- PersistentVolumeClaim（PVC）：用户对存储资源的请求描述，包含容量、访问模式、存储类等需求，Kubernetes 负责将 PVC 绑定到匹配的 PV。
- StorageClass（SC）：存储类模板，定义动态供给的存储后端类型、回收策略、挂载参数等，实现“按需分配”的存储消费模式。
设计哲学：PV/PVC 机制将“存储的提供”与“存储的使用”彻底分离。集群管理员关注 PV 和 StorageClass 的配置，应用开发者只需声明 PVC，无需关心底层存储实现细节。
1.3 云原生存储与传统存储对比
传统存储架构（如 SAN/NAS 集中式存储）与云原生存储（如 CSI 驱动、分布式存储）在设计理念、运维模式、弹性能力上存在本质差异：
| 对比维度 | 传统存储 | 云原生存储 |
|---|---|---|
| 供给方式 | 手动 LUN 创建、手动挂载 | PVC → StorageClass 自动动态供给 |
| 生命周期 | 与物理服务器绑定，迁移困难 | 独立于 Pod，支持跨节点漂移 |
| 扩展性 | 垂直扩展为主，受限于控制器 | 水平扩展，分布式架构无单点瓶颈 |
| 接口标准 | 厂商私有 API / 协议 | CSI 统一接口，多云一致体验 |
| 运维模式 | 人工运维、变更窗口长 | 声明式 API + Operator 自动化运维 |
| 故障恢复 | 依赖 RAID / 双活控制器 | 副本 + 自愈 + 跨 AZ 拓扑感知 |
| 可观测性 | 独立监控系统，与编排脱节 | Metrics API + Prometheus 集成 |
迁移避坑：将传统存储迁移到云原生环境时，切忌“直接挂载原有 LUN 到 Pod”。必须通过 CSI 驱动重新适配，并设计合理的 StorageClass 回收策略（Retain / Delete / Recycle），否则可能导致数据残留或意外删除。
1.4 本章小结
- Kubernetes 存储从 v1.0 的临时卷发展到 v1.13+ 的 CSI GA 成熟生态，经历了四个关键阶段。
- 存储资源模型以 PV、PVC、StorageClass 三大核心原语实现“声明式存储消费”，用户与存储实现解耦。
- 云原生存储相比传统存储，在动态供给、水平扩展、接口标准化、自动化运维方面具有显著优势。
- 理解存储资源模型是后续学习卷快照、卷克隆、拓扑感知调度、数据传输优化等高级主题的基础。