Kubernetes 存储系统 Storage 介绍

       容器中的存储都是临时的，因此Pod重启的时候，内部的数据会发生丢失。实际应用中，我们有些应用是无状态，有些应用则需要保持状态数据，确保Pod重启之后能够读取到之前的状态数据，有些应用则作为集群提供服务。这三种服务归纳为无状态服务、有状态服务以及有状态的集群服务，其中后面两个存在数据保存与共享的需求，因此就要采用容器外的存储方案。

1、Kubernetes中存储中有四个重要的概念：

Volume、PersistentVolume PV、PersistentVolumeClaim PVC、StorageClass

一、存储系统核心概念

  1. Volume（卷）

    • 定义：Kubernetes 中最基础的存储单元，用于将外部存储挂载到 Pod 中的容器。

    • 特点：

      • 生命周期与 Pod 绑定（Pod 删除则 Volume 销毁，但部分类型如 PV 可持久化）。

      • 支持多种存储类型：本地存储（emptyDir、hostPath）、网络存储（NFS、CephFS）、云存储（AWS EBS、GCE PD）等。

    • 典型用法：

      volumes:                   # 定义存储类型
- name: data
  hostPath:
    path: /mnt/data
volumeMounts:             # 挂载到容器路径
- name: data
  mountPath: /app/data

  2. PersistentVolume（PV，持久卷）

    • 定义：集群级别的存储资源（如一块云磁盘、一个 Ceph RBD 镜像），由管理员预先创建。

    • 核心属性：

      • capacity：存储容量（如 10Gi）。

      • accessModes：访问模式（单节点读写 ReadWriteOnce、多节点只读 ReadOnlyMany、多节点读写 ReadWriteMany）。

      • persistentVolumeReclaimPolicy：回收策略（保留 Retain、删除 Delete）。

    • 示例：

      apiVersion: v1
kind: PersistentVolume
metadata:
  name: ceph-pv
spec:
  capacity: { storage: 10Gi }
  accessModes: [ReadWriteOnce]
  cephfs:
    monitors: ["ceph-mon:6789"]
    path: /data
  storageClassName: ceph-storage

  3. PersistentVolumeClaim（PVC，持久卷声明）

    • 定义：用户对存储资源的“需求清单”，声明所需的存储大小、访问模式等，由 Kubernetes 自动绑定到匹配的 PV。

    • 核心属性：

      • resources.requests.storage：请求的存储大小（如 5Gi）。

      • storageClassName：指定动态供给的存储类型。

    • 示例：

      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: app-data-pvc
spec:
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 5Gi
  storageClassName: ceph-storage

  4. StorageClass（存储类）

    • 定义：动态供给的模板，定义如何按需创建 PV（例如自动创建云盘或 Ceph RBD 镜像）。

    • 核心属性：

      • provisioner：存储驱动（如 kubernetes.io/aws-ebs）。

      • parameters：存储后端参数（如 Ceph 集群地址）。

    • 示例：

      apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph-rbd
provisioner: kubernetes.io/rbd
parameters:
  monitors: ceph-mon:6789
  adminId: admin
  pool: kube
二、静态 PV vs 动态 PV
特性 静态 PV 动态 PV
创建方式 管理员手动创建 PV 通过 StorageClass 自动创建 PV
适用场景 固定存储需求、预定义存储资源 弹性伸缩、按需分配存储资源
运维复杂度 高（需手动管理 PV） 低（自动管理）
Ceph 示例 需提前创建 RBD 镜像 自动创建 RBD 镜像
工作流程 PV → PVC → Pod PVC → StorageClass → PV → Pod
资源利用率 可能浪费（需预先分配） 高效（按需分配）

四大核心概念的协同关系

  1. 抽象层级关系
    Volume（基础存储单元） → PV（持久化存储资源） → PVC（存储资源声明） → StorageClass（动态供给模板）

  2. 工作流程对比
    静态供给：
    管理员创建PV → 用户创建PVC → 系统绑定PV/PVC → Pod使用PVC

         动态供给：
         用户创建PVC → StorageClass自动创建PV → 系统绑定 → Pod使用PVC

三、核心流程对比

  1. 静态 PV 工作流程

    • 步骤：

      1. 管理员创建 PV（如 Ceph RBD 镜像）。

      2. 用户创建 PVC，声明存储需求。

      3. Kubernetes 将 PVC 绑定到匹配的 PV。

      4. Pod 挂载 PVC。

    • 痛点：需人工维护大量 PV，存储扩容需手动操作。

  2. 动态 PV 工作流程

    • 步骤：

      1. 管理员创建 StorageClass（定义存储类型）。

      2. 用户创建 PVC，指定 StorageClass。

      3. Kubernetes 自动创建 PV 并绑定 PVC。

      4. Pod 挂载 PVC。

    • 优势：自动化创建存储资源，适合云环境弹性需求。

     动态供给革命性突破

  1. 传统静态供给痛点

  • 需预先创建大量PV资源

  • 存储管理员需手动对接存储系统

  • 资源利用率难以优化

  • Ceph场景需人工创建RBD image

  1. 动态供给优势

  • 按需自动创建存储资源

  • 自动化对接存储后端

  • 资源弹性伸缩

  • Ceph场景自动生成RBD image

四、存储系统其他核心知识点

  1. Volume 类型详解

    • emptyDir：临时存储，Pod 删除后数据丢失，适合缓存。

    • hostPath：挂载节点本地目录，慎用于生产（数据与节点强绑定）。

    • local：持久化本地卷，需通过 PV 定义节点亲和性，适合数据库类应用。

    • nfs/cephfs：共享文件存储，支持多节点读写。

  2. PV 回收策略（Reclaim Policy）

    • Retain：删除 PVC 后保留 PV 和数据，需手动清理。

    • Delete：删除 PVC 时自动删除 PV 和后端存储（如云盘）。

    • Recycle（已弃用）：清空数据，供新 PVC 使用。

  3. 访问模式（Access Modes）

    • ReadWriteOnce (RWO)：单节点读写（如本地 SSD）。

    • ReadOnlyMany (ROX)：多节点只读（如配置文件）。

    • ReadWriteMany (RWX)：多节点读写（如 NFS 共享目录）。

  4. 存储拓扑感知（Topology）

    • 动态 PV 支持 WaitForFirstConsumer 模式，延迟 PV 创建直到 Pod 调度，确保存储与 Pod 在同一可用区。

五、Ceph RBD 动态 PV 实战示例

  1. 创建 StorageClass

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph-rbd
provisioner: kubernetes.io/rbd
parameters:
  monitors: ceph-mon-1:6789,ceph-mon-2:6789
  adminId: admin
  adminSecretName: ceph-admin-secret
  pool: kube
  userId: kube-user
  userSecretName: ceph-user-secret

  2. 创建 PVC（触发动态 PV 创建）

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mysql-data
spec:
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 20Gi
  storageClassName: ceph-rbd

  3. Pod 挂载 PVC

    apiVersion: v1
kind: Pod
metadata:
  name: mysql
spec:
  containers:
  - name: mysql
    image: mysql:8.0
    volumeMounts:
    - name: data
      mountPath: /var/lib/mysql
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: mysql-data
六、总结

  • 无状态应用：优先使用 emptyDir 或临时卷。

  • 有状态应用：必用 PV/PVC，根据场景选择静态或动态供给。

  • 性能敏感型：本地 PV（local 类型）或云 SSD 卷。

  • 共享存储：CephFS、NFS 等支持 ReadWriteMany 的存储。

通过 StorageClass 实现动态供给，是 Kubernetes 存储设计的精髓，它让存储资源可以像 CPU、内存一样“声明式使用”，是云原生架构的关键支柱。

附加解释：

RWO、ROX、RWX​​ 

一、缩写与全称对照

缩写 英文全拼 组成分解 官方定义场景
RWO ​​ReadWriteOnce​​ Read（读） + Write（写） + Once（单节点） 单节点独占读写权限
ROX ​​ReadOnlyMany​​ Read（读） + Only（仅） + Many（多节点） 多节点共享只读权限
RWX ​​ReadWriteMany​​ Read（读） + Write（写） + Many（多节点） 多节点共享读写权限

​​注意​​：

  • ​​ROX 中的 "X" 是 "Many" 的缩写​​（非字面字母），代表多节点；
  • ​​RWX 是唯一支持多节点读写的模式​​（如 NFS）。

二、官方解释 vs 通俗比喻

1. ​​RWO（ReadWriteOnce）​​
  • ​​官方定义​​：
    存储卷只能被一个节点（Node）以读写模式挂载，适用于需要独占写入的场景（如数据库）。
  • ​​通俗比喻​​：
    类似 ​​U盘​​ —— 插到一台电脑上时，其他电脑无法同时读写，保证数据一致性。
2. ​​ROX（ReadOnlyMany）​​
  • ​​官方定义​​：
    存储卷可被多个节点挂载，但所有节点只能读取数据，不能修改（如配置文件、静态资源）。
  • ​​通俗比喻​​：
    类似 ​​公告牌​​ —— 所有人可同时查看内容，但无人能修改公告内容。
3. ​​RWX（ReadWriteMany）​​
  • ​​官方定义​​：
    存储卷可被多个节点同时挂载并读写，依赖共享文件系统（如 NFS、CephFS）。
  • ​​通俗比喻​​：
    类似 ​​共享云盘​​ —— 多人在线编辑同一文档，实时同步修改（但需解决冲突）。

三、实际应用场景对比

模式 典型应用场景 技术实现示例 限制条件
RWO 数据库（MySQL、PostgreSQL） 本地磁盘、云硬盘（如AWS EBS） 仅单节点读写
ROX 配置文件、静态网页 ConfigMap、只读NFS 多节点只读，不可写入
RWX 日志收集、多人协作编辑 NFS、CephFS、GlusterFS 需网络共享存储支持

四、选择建议

  • ​​单机服务​​（如数据库）：用 ​​RWO​​（避免数据冲突）；
  • ​​只读共享​​（如配置文件）：用 ​​ROX​​（安全且高效）；
  • ​​多节点协作​​（如数据分析）：用 ​​RWX​​（需存储系统支持多写）。
# kubernetes # 容器 # 云原生
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

昆仑万维天工超级智能体：AI Office新纪元与多模态创作

avatar AI Agent技术社区
cover

微软重磅开源Magentic-UI！彻底改写AI智能体交互方式，开创人与AI智能体协作新时代， 支持浏览器调用+文件操作+代码生成！从部署到测评！保姆级教程！小白也能3分钟零代码打造自己的智能体

avatar AI Agent技术社区
cover

【AI实战】从“苦AI”到“爽AI”：Magentic-UI 把“人类-多智能体协作”玩明白了！

avatar AI Agent技术社区