Code Guide

外观

K8S存储卷概述

约 6134 字大约 20 分钟

2025-09-04

存储卷概述

1 存储卷概述

Pod本身具有生命周期，这就带了一系列的问题，第一，当一个容器损坏之后，kubelet会重启这个容器，但是文件会丢失-这个容器会是一个全新的状态；第二，当很多容器在同一Pod中运行的时候，很多时候需要数据文件的共享。Docker支持配置容器使用存储卷将数据持久存储于容器自身文件系统之外的存储空间之中，它们可以是节点文件系统或网络文件系统之上的存储空间。相应的，kubernetes也支持类似的存储卷功能，不过，其存储卷是与Pod资源绑定而非容器。

简单来说，存储卷是定义在Pod资源之上、可被其内部的所有容器挂载的共享目录，它关联至某外部的存储设备之上的存储空间，从而独立于容器自身的文件系统，而数据是否具有持久能力取决于存储卷自身是否支持持久机制。Pod、容器与存储卷的关系图如下。

img

2 Kubernetes支持的存储卷类型

Kubernetes支持非常丰富的存储卷类型，包括本地存储（节点）和网络存储系统中的诸多存储机制，还支持Secret和ConfigMap这样的特殊存储资源。例如，关联节点本地的存储目录与关联GlusterFS存储系统所需要的配置参数差异巨大，因此指定存储卷类型时也就限定了其关联到的后端存储设备。通过命令# kubectl explain pod.spec可以查看当前kubernetes版本支持的存储卷类型。常用类型如下：

  • 非持久性存储
  • emptyDir
  • hostPath
  • 网络连接性存储
  • SAN：iscsi
  • NFS：nfs、cfs
  • 分布式存储
  • glusterfs、cephfs、rbd
  • 云端存储
  • awsElasticBlockStore、azureDisk、gitRepo

3 存储卷的使用方式

在Pod中定义使用存储卷的配置由两部分组成：一是通过.spec.volumes字段定义在Pod之上的存储卷列表，其支持使用多种不同类型的存储卷且配置参数差别很大；另一个是通过.spce.containers.volumeMounts字段在容器上定义的存储卷挂载列表，它只能挂载当前Pod资源中定义的具体存储卷，当然，也可以不挂载任何存储卷。

在Pod级别定义存储卷时，.spec.volumes字段的值为对象列表格式，每个对象为一个存储卷的定义，由存储卷名称（.spec.volumes.name <string>）或存储卷对象（.spec.volumes.VOL_TYPE <Object>）组成，其中VOL_TYPE是使用的存储卷类型名称，它的内嵌字段随类型的不同而不同。下面示例定义了由两个存储卷组成的卷列表，一个为emptyDir类型，一个是gitRepo类型。

......
volumes:
- name: data
  emptyDir: {}
- name: example
  gitRepo:
    repository: https://github.com/ikubernetes/k8s_book.git
    revision: master
    directory:

无论何种类型的存储卷，挂载格式基本上都是相同的，通过命令# kubectl explain pod.spec.containers.volumeMounts 可以进行查看。在容器中顶一个挂载卷时的通用语法形式如下：

......
volumeMounts:
- name	<string> -required-      #指定要挂载的存储卷的名称，必选字段
  mountPath	<string> -required-  #挂载点路径，容器文件系统的路径，必选字段
  readOnly	<boolean>            #是否挂载为只读卷
  subPath	<string>             #挂载存储卷时使用的子路径，及mountPath指定的路径下使用一个子路径作为其挂载点。

示例，容器myapp将上面定义的data存储卷挂载于/var/log/myapp，将examply挂载到/webdata/example目录。

spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    volumeMounts:
    - name: data
      mountPath: /var/log/myapp/
    - name: example
      mountPath: /webdata/example/

4 存储卷使用示例

下面的所有示例的资源清单文件都放在新建的storage目录中。

[root@k8s-master ~]# mkdir storage
[root@k8s-master ~]# cd storage/

4.1 emptyDir 存储卷

emptyDir存储卷是Pod对象生命周期中的一个临时目录，类似于Docker上的“docker 挂载卷”，在Pod对象启动时即被创建，而在Pod对象被移除时会被一并删除（永久删除）。Pod中的容器都可以读写这个目录，这个目录可以被挂载到各个容器相同或者不相同的路径下。注意：一个容器崩溃了不会导致数据的丢失，因为容器的崩溃并不移除Pod。

emptyDir的作用：

  1. 普通空间，基于磁盘的数据存储
  2. 作为从崩溃中恢复的备份点
  3. 存储那些需要长久保存的数据，例如web服务中的数据

emptyDir字段说明：

[root@k8s-master ~]# kubectl explain pod.spec.volumes.emptyDir
medium	<string>：    #此目录所在的存储介质的类型，可取值为“default”或“Memory”，默认为default，表示使用节点的的默认存储介质；Memory表示使用基于RAM的临时的文件系统temfs，空间受限于内存，但性能非常好，通常用于为容器中的应用提供缓存空间。
sizeLimit	<string>    #当前存储卷的空间限额，默认值为nil，表示不限制；不过，在medium字段值为“Memory”时建议务必定义此限额。

emptyDir示例：

这里定义了一个Pod资源对象（vol-emptydir-pod），在其内部定义了两个容器，其中一个容器是辅助容器sidecar，每隔10秒生成一行信息追加到index.html文件中；另一个是nginx容器，将存储卷挂载到站点家目录。然后访问nginx的html页面验证两个容器之间挂载的emptyDir实现共享。

img

1）编辑资源清单文件

2）创建并查看状态

[root@k8s-master storage]# kubectl apply -f vol-emptydir.yaml 
pod/vol-emptydir-pod created
[root@k8s-master storage]# kubectl get pods -o wide 
NAME               READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
vol-emptydir-pod   2/2     Running   0          63s   10.244.2.79   k8s-node2   <none>           <none>

3）访问测试

4.2 hostPath 存储卷

hostPath类型的存储卷是指将工作节点上的某文件系统的目录或文件挂载于Pod中的一种存储卷，独立于Pod资源的生命周期，具有持久性。在Pod删除时，数据不会丢失。

img

hostPath字段说明：

hostPath示例：

1）编辑资源清单文件

2）创建并查看状态

[root@k8s-master storage]# kubectl apply -f vol-hostpath.yaml 
pod/vol-hostpath-pod created
[root@k8s-master storage]# kubectl get pods -o wide 
NAME               READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
vol-hostpath-pod   1/1     Running   0          7s    10.244.1.83   k8s-node1   <none>           <none>

3）通过上面查看pod被调度到节点1上面，查看节点1的目录并创建测试文件

[root@k8s-node1 ~]# ll /data/pod/volume1/
总用量 0
[root@k8s-node1 ~]# echo "<h1>kubernetes hostPath test</h1>" >> /data/pod/volume1/index.html

4）访问测试，及删除测试

[root@k8s-master storage]# curl 10.244.1.83
<h1>kubernetes hostPath test</h1>

#删除pod资源再次查看节点1上面的文件
[root@k8s-master storage]# kubectl delete -f vol-hostpath.yaml 
pod "vol-hostpath-pod" deleted
[root@k8s-node1 ~]# ll /data/pod/volume1/
总用量 4
-rw-r--r-- 1 root root 34 10月  9 16:09 index.html

4.3 nfs 存储卷

nfs存储卷用于将事先存在的NFS服务器上导出的存储空间挂载到Pod中供容器使用。与emptyDir不同的是，当pod资源删除时emptyDir也会被删除，而NFS在Pod对象删除时仅是被卸载而非删除。这就意味NFS能够允许我们提前对数据进行处理，而且这些数据可以在Pod之间相互传递，并且NFS可以同时被多个Pod挂载并进行读写。

nfs字段说明：

[root@k8s-master ~]# kubectl explain pod.spec.volumes.nfs
server	<string> -required-    #NFS服务器的IP地址或主机名，必选字段
path	<string> -required-    #NFS服务器导出（共享）的文件系统路径，必选字段
readOnly	<boolean>          #是否以只读方式挂载，默认为false

nfs示例：

1）首先准备一个nfs服务器

2）编辑资源清单文件

[root@k8s-master storage]# vim vol-nfs.yaml

3）创建并查看状态

[root@k8s-master storage]# kubectl apply -f vol-nfs.yaml 
pod/vol-nfs-pod created
[root@k8s-master storage]# kubectl get pods 
NAME          READY   STATUS    RESTARTS   AGE
vol-nfs-pod   1/1     Running   0          45s
[root@k8s-master storage]# kubectl get pods -o wide
NAME          READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
vol-nfs-pod   1/1     Running   0          51s   10.244.2.80   k8s-node2   <none>           <none>

4）测试验证

通过上面测试可以看出，此前创建的mykey及其数据在Pod资源重建后依然存在，且不论pod资源调度到哪个节点。这表明在删除Pod资源时，其关联的外部存储卷并不会被一同删除。如果需要删除此类的数据，需要用户通过存储系统的管理接口手动进行。

5 PVC与PV

5.1 介绍

前面提到Kubernetes提供那么多存储接口，但是首先Kubernetes的各个Node节点能管理这些存储，但是各种存储参数也需要专业的存储工程师才能了解，由此我们的Kubernetes管理变的更加复杂。由此kubernetes提出了PV和PVC的概念，这样开发人员和使用者就不需要关注后端存储是什么，使用什么参数等问题。如下图：

img

PV：

PersistentVolume（PV）是集群中已由管理员配置的一段网络存储。集群中的资源就像一个节点是一个集群资源。PV是诸如卷之类的卷插件，但是具有独立于使用PV的任何单个Pod的生命周期。该API对象捕获存储的实现细节，即NFS，ISCSI或云提供商特定的存储系统。

PVC：

PersistentVolumeClaim（PVC）是用户存储的请求。它类似于Pod。Pod消耗节点资源，PVC消耗存储资源。Pod可以请求特定级别的资源（CPU和内存）。权限要求可以请求特定的大小和访问模式。

虽然PersistentVolumeClaims允许用户使用抽象存储资源，但是常见的是，用户需要具有不同属性（如性能）的PersistentVolumes，用于不同的问题。集群管理员需要能够提供多种不同于PersistentVolumes的PersistentVolumes，而不仅仅是大小和访问模式，而不会使用户了解这些卷的实现细节。对于这些需求，存在StorageClass资源。

StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。不同的类可能映射到服务质量级别，或备份策略，或者由集群管理员确定的任意策略。Kubernetes本身对于什么类别代表是不言而喻的。这个概念有时在其它存储系统中称为“配置文件”

5.2 生命周期

PV是集群中的资源。PVC是对这些资源的请求，也是对资源的索赔检查。PV和PVC之间的相互作用遵循这个生命周期：

Provisioning—>Binding—>Using—>Releasing—>Recycling

供应准备Provisioning

PV有两种提供方式：静态或者动态

  • Static：集群管理员创建多个PV。它们携带可供集群用户使用的真实存储的详细信息。它们存在于Kubernetes API中，可用于消费。
  • Dynamic：当管理员创建的静态PV都不匹配用户的PersistentVolumesClaim时，集群可能会尝试为PVC动态配置卷。此配置基于StorageClasses：PVC必须请求一个类，并且管理员必须已经创建并配置该类才能进行动态配置。要求该类的声明有效地位自己禁用动态配置。

绑定Binding

用户创建PVC并指定需要的资源和访问模式。在找到可用PV之前，PVC会保持未绑定状态。

使用Using

用户可在Pod中像volume一样使用PVC。

释放Releasing

用户删除PVC来回收存储资源，PV将变成“released”状态。由于还保留着之前的数据，这些数据要根据不同的策略来处理，否则这些存储资源无法被其它PVC使用

回收Recycling

PV可以设置三种回收策略：保留（Retain）、回收（Recycle）和删除（Delete）。

5.3 创建PV

字段说明：

PersistentVolume Spec主要支持以下几个通用字段，用于定义PV的容量、访问模式、和回收策略

5.4 创建PVC

字段说明：

PersistentVolumeClaim是存储卷类型的资源，它通过申请占用某个PersistentVolume而创建，它与PV是一对一的关系，用户无须关系其底层实现细节。申请时，用户只需要指定目标空间的大小、访问模式、PV标签选择器和StorageClass等相关信息即可。PVC的Spec字段的可嵌套字段具体如下：

5.5 在Pod中使用PVC

在Pod资源中调用PVC资源，只需要在定义volumes时使用persistentVolumeClaims字段嵌套指定两个字段即可。具体如下：

[root@k8s-master ~]# kubectl explain pod.spec.volumes.persistentVolumeClaim
claimName	<string> -required-    #要调用的PVC存储卷的名称，PVC卷要与Pod在同一名称空间中
readOnly	<boolean>    #是否将存储卷挂载为只读模式，默认为false。

5.6 示例使用PVC和PV

说明：下面示例中，准备了一台NFS Server创建了几个共享目录提供给Kubernetes作为PV使用。在创建PV的同时指定了不同的大小和不同的访问权限，然后在创建PVC时候指定了大小为6Gi，故满足条件的PV只有pv003~pv005，这里通过标签选择器选择了pv003。Pod中的容器使用了MySQL，并将MySQL的数据目录挂载到PV上。示例图如下：

img

1）准备NFS服务

2）创建PV；这里创建5个PV，存储大小各不相等，是否可读也不相同

3）创建PVC，绑定PV

4）查询验证pv和pvc

5）测试验证

贡献者

codingLab

版权归属：codingLab

许可证：bugcode

Code Guide © 2020-2025

项导文档说明

2025-08-17
- 已迁移至 docs.code-guide