Kubernetes_存储体系深度解析与实验指南 (1)

一、存储体系核心概念 1.1 Kubernetes 为什么需要存储抽象

容器本身是无状态的——容器重启或销毁后，其内部文件系统的变更全部丢失。为了支撑有状态应用（数据库、消息队列、文件服务等），Kubernetes 引入了**Volume（卷）**机制，将存储生命周期与容器解耦。citeweb_search:6

K8s 存储体系的核心设计哲学是分层解耦：

└─────────────────────────────────────────────────────────────────────┘

核心原则：Volume 与 Pod 绑定，Pod 删除后 Volume 销毁（PV 除外）。citeweb_search:6

Kubernetes 存储按持久化能力和共享能力可分为以下类型：citeweb_search:6

二、基础存储类型详解 2.1 emptyDir：Pod 级临时存储

emptyDir是最简单的卷类型。当 Pod 被调度到节点时，kubelet 在节点上创建一个空目录并挂载到容器。Pod 删除后，数据永久丢失。citeweb_search:6

 emptyDir: {}

特性总结：citeweb_search:6

适用场景：

• 容器间共享临时数据（如 Nginx + sidecar 日志采集）

• 应用运行时缓存、排序缓冲区

• 不需要持久化的临时工作目录

hostPath将节点上的文件或目录直接挂载到容器中。Pod 删除后数据保留在节点上，但 Pod 迁移到新节点后数据不跟随。citeweb_search:6

# 目录不存在则自动创建

hostPath type 选项：citeweb_search:6

⚠️ 安全风险：hostPath 存在严重的安全风险，最佳做法是尽可能避免使用。当必须使用时，范围应仅限于所需的文件或目录，并以只读方式挂载。citeweb_search:6

适用场景：

• 单节点测试环境

• 节点级日志采集（DaemonSet 读取宿主机日志）

• 访问节点设备（如 GPU 设备文件）

PV/PVC 是 Kubernetes 持久化存储的两层抽象模型：citeweb_search:6

└─────────────────────────────────────────────────────────────┘

PV 关键字段：citeweb_search:6

访问模式（Access Modes）：

注意：访问模式是 PV 的能力声明，不是强制限制。例如 NFS 支持 RWM，但 EBS 仅支持 RWO。citeweb_search:6

回收策略（Reclaim Policy）：

生产建议：务必使用 Retain 策略，这是误删 PVC 后数据恢复的唯一保障。citeweb_search:6

StorageClass 定义了存储的动态供给规则，实现了存储资源的自动化管理。citeweb_search:6

# 延迟绑定（Local PV 必备）

关键字段：citeweb_search:6

重要：volumeBindingMode: WaitForFirstConsumer 是 Local PV 的必备配置，确保 PV 创建在 Pod 调度的目标节点上。citeweb_search:6

Local PV 将节点本地磁盘纳入 Kubernetes 存储抽象，通过标准 PVC 接口访问。与 hostPath 不同，Local PV 有完整的 PV/PVC 生命周期管理。citeweb_search:6

 - worker-node-1

特性：

• 性能极高（本地磁盘，无网络开销）

• 有 nodeAffinity 调度约束，Pod 必须调度到 PV 所在节点

• 单节点故障会导致数据不可用（需应用层实现高可用）

适用场景：高性能数据库（如 etcd、MySQL）、需要低延迟的存储密集型应用。citeweb_search:6

2.6 CSI（Container Storage Interface）

CSI 是 Kubernetes 的标准化存储插件接口，允许第三方存储系统（Ceph、AWS EBS、NFS 等）与 K8s 集成，无需修改 K8s 核心代码。citeweb_search:6

└─────────────────────────────────────────────────────────────┘

主流 CSI 驱动：citeweb_search:6

三、StatefulSet 存储设计 3.1 为什么 StatefulSet 需要特殊存储设计

Deployment 将 Pod 视为可互换的——Pod 重建后获得新名称、新 IP、新存储。但对于数据库、消息队列等有状态应用，每个 Pod 需要：citeweb_search:6

3.2 StatefulSet 的 volumeClaimTemplates

StatefulSet 通过 volumeClaimTemplates 为每个 Pod 动态创建独立的 PVC，实现 Pod 与存储的一对一绑定。citeweb_search:6

 storage: 1Gi

生成的资源：citeweb_search:6

PV: pv-xxx-0, pv-xxx-1, pv-xxx-2 (由 StorageClass 动态创建)

关键特性：即使 Pod 被重新调度到其他节点，Kubernetes 仍会基于 PVC 名称挂载原有的 PV，保障数据与 Pod 标识的强绑定关系。citeweb_search:6

StatefulSet 的 persistentVolumeClaimRetentionPolicy 控制缩容时 PVC 的行为：citeweb_search:6

# ...

生产保命配置：whenScaled: Retain 是生产环境的保命配置，防止缩容时误删数据。citeweb_search:6

 storage: 1Gi

• Kubernetes 集群（v1.24+）

• kubectl 已配置

• 所有节点创建 /data/k8s-storage 目录

mkdir -p /data/k8s-storage

目标：验证 emptyDir 在同 Pod 多容器间的共享能力，以及 Pod 删除后数据丢失。

步骤 1：创建测试 Pod

 emptyDir: {}

#

步骤 2：验证 Pod 删除后数据丢失

# 预期：文件不存在或为空，证明数据已丢失

目标：验证 hostPath 将宿主机目录映射到容器。

步骤 1：在节点上准备数据

echo ”HostPath test data” > /data/k8s-storage/hostpath-demo/index.html

步骤 2：创建 hostPath Pod

 type: Directory

# 预期：包含 ”New data from container”

步骤 3：验证节点绑定

# 如果调度到不同节点，数据将丢失！

⚠️ 注意：hostPath 数据与节点绑定，Pod 迁移后数据不跟随。这是生产环境不推荐 hostPath 的核心原因。

目标：手动创建 PV 和 PVC，理解静态供给流程。

步骤 1：创建静态 PV

 path: /data/k8s-storage/pv-10gi

# 预期：STATUS = Available（未绑定）

步骤 2：创建 PVC 绑定 PV

 storage: 10Gi

# 预期：STATUS = Bound，CLAIM = default/static-pvc

步骤 3：Pod 使用 PVC

 claimName: static-pvc

# cat /data/k8s-storage/pv-10gi/test.txt

步骤 4：验证 Retain 策略

rm -rf /data/k8s-storage/pv-10gi

目标：使用 NFS Subdir External Provisioner 实现 PVC 动态创建 PV。

步骤 1：部署 NFS Provisioner（简化版，使用 local-path 模拟）

# 预期：local-path 类型

步骤 2：创建动态 PVC

 storage: 1Gi

# 预期：出现一个 NAME 为 pvc-xxx 的 PV，自动创建

步骤 3：Pod 使用动态 PVC

 claimName: dynamic-pvc

# 预期：Dynamic provisioning works!

步骤 4：验证 Delete 回收策略

# 预期：对应的 PV 已被自动删除（因为 local-path 默认 reclaimPolicy=Delete）

目标：验证 StatefulSet 为每个 Pod 创建独立 PVC，以及 Pod 重建后数据保留。

步骤 1：创建 StatefulSet

 storage: 100Mi

# 预期：3 个 PV 自动创建

步骤 2：验证每个 Pod 独立存储

# 预期：每个 Pod 包含不同的 hostname 和创建时间

步骤 3：验证 Pod 重建后数据保留

# 预期：数据与删除前一致！PVC 绑定的 PV 被重新挂载

步骤 4：缩容验证（观察 PVC 保留）

# 预期：数据与缩容前一致

目标：验证 PVC 在线扩容。

# 预期：CAPACITY 变为 200Mi

kubectl get statefulset

# 4. Local PV 的节点亲和性导致 Pod 无法调度到正确节点

# 2. 清理数据后重新创建 PV 或等待动态供给

# 解决方案：确保 PV 的 nodeAffinity 与 Pod 调度目标一致

 mountPath: /data

实践

优先使用动态供给

通过 StorageClass 自动创建 PV，避免手动管理

生产环境使用 Retain

防止误删 PVC 导致数据丢失

StatefulSet 设置 PVC Retention

whenScaled: Retain防止缩容丢数据

Local PV 使用 WaitForFirstConsumer

确保 PV 创建在 Pod 调度的目标节点

分离数据与配置

StatefulSet 使用多个 volumeClaimTemplates，数据与配置分开存储

监控存储容量

通过 Prometheus 监控 PVC 使用率，提前扩容

定期备份

使用 VolumeSnapshot 或应用层备份工具

避免 hostPath 生产使用

安全风险高，节点绑定导致调度受限

八、总结

Kubernetes 存储体系的核心是PV/PVC 的两层抽象：管理员或 StorageClass 负责提供存储资源，应用通过 PVC 声明式申请。理解了这个抽象，就能理解所有存储卷类型的共同基础。citeweb_search:6

掌握 Kubernetes 存储体系，是构建可靠有状态应用、保障数据安全的基础能力。