Kubernetes持久化存储详解：Volume、emptyDir、hostPath与StorageClass-优快云博客

本文链接：https://blog.youkuaiyun.com/NickDeCodes/article/details/133098383

kubernetes持久化存储数据

Kubernetes的卷Volume
实战挂载NFS卷
- 应用场景
- 挂载NFS卷
持久化存储PersistantVolume
- 介绍
PVC持久化卷Claim
- PersistentVolumeClaims
存储类Storage Class

Kubernetes的卷Volume

卷

容器中的文件在磁盛上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失一一因为容器会以干净的状态重建。其次，当在一个Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件。Kubernetes 抽象出 Volume 对象来解决这两个问题。

背景

Docker 也有volume 的概念，但对它只有少量且松散的管理。在Docker 中，volume 是磁盛上或者另外一个容器内的一个目录。直到最近，Docker 才支持对基于本地磁盘的 Volume 的生存期进行管理。虽然Docker 现在也能提供 volume 驱动程序，但是目前功能还非常有限（例如，截至 Docker 1.7，每个容器只允许有一个 volume 驱动程序，并且无法将参数传递给卷）。

另一方面，Kubernetes 卷具有明确的生命周期一一与包裹它的 Pod 相同。因此，卷比Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。当然，当一个 Pod 不再存在时，卷也将不再存在。也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。

卷的核心是包含一些数据的目录，Pod 中的容器可以访问该目录。特定的卷类型可以決定这个目录如何形成的，并能决定它支持何种介质，以及目录中存放什么内容。

使用卷时，Pod 声明中需要提供卷的类型（spec.volumes 字段)和卷挂载的位置 (-spec.containers.volumeMounts 字段）.

Kubernetes提供了众多的volume类型，包括erptyDir、hostPath、 nts. glusterts、cephts、ceph，我们来讲讲 emptyDir:

emptyDir

当Pod指定到某个节点上时，首先创建的是一个emptyDir 卷，并且只要 Pod 在该节点上运行，卷就一直存在。就像它的名称表示的那样，卷最初是空的。尽管 Pod 中的容器挂载 emptyDir 卷的路径可能相同也可能不同，但是这些容器都可以读写 empty Dir卷中相同的文件。当Pod 因为某些原因被从节点上删除时，emptyDir 卷中的数据也会永久删除。

说明：容器崩溃并不会导致Pod 被从节点上移除，因此容器崩溃时 emptyDir 卷中的数据是安全的。

emptyDir 的一些用途：

缓存空问，例如基于磁盘的并排序。
为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。
在web服务器容器服务数据时，保存内容管理器类型容器获取的文件。

hostPath

hostPath卷能将主机节点文件系统上的文件或目录挂载到Pod中。虽然这不是大多数Pod需要的，但是它为一些应用程序提供了强大的持久化能力。

实战挂载NFS卷

应用场景

很多应用需要在集群内部有一个统一的地方在存储文件，比如图片，日志等等，而使用 hostPath 方式并不灵活，因为你需要制定host 的地址。

挂载NFS卷

在Master 和所有Worker node 安装nts 服务
```
yum install -y nfs-utils rpcbind
```
修改配置vi /etc/exports
```
/nfsdata   *(rw,sync,no_root_squash)
```

在master 节点系统自动启动

systemctl enable --now rpcbind
systemctl enable --now nfs

如果修改了/etc/exports，需要重新激活配置
```
exportfs -r
```

查看nfs挂载效果

[root@master Chapter8]# showmount -e master
Export list for master:
/nfsdata *

这样即为挂载/nfsdata成功。

创建Pod 引用 NFS 存储：

执行代码：kubectl apply -f 8-2-nfs.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nfs-pd
spec:
  containers:
  - name: test-container
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: master
      path: /nfsdata

查看pod 挂载目录

执行：

kubectl describe pod myapp

可以看到成功挂载了 NFS 类型的目录

Volumes:
  nfs:
    Type:      NFS (an NFS mount that lasts the lifetime of a pod)
    Server:    master
    Path:      /nfsdata
    ReadOnly:  false

持久化存储PersistantVolume

介绍

存储的管理是一个与计算实例的管理完全不同的问题。PersistentVolume 子系统为用户和管理员提供了一组 AP，将存储如何供应的细节从其如何被使用中抽象出来。为了实现这点，我们引入了两个新的 API资源：Persistentvolume 和 PersistentVolumeClaim.

持久卷 (PersistentVolume， PV）是集群中的一块存储，可以由管理员事先供应，或者使用存储类 (Storage Class) 来动态供应。持久卷是集群资源，就像节点也是集群资源一样。PV持久卷和普通的 volume 一样，也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的Pod 的生命周期。此 API 对象中记述了存储的实现细节，无论其背后是 NFS、isCS1 还是特定于云平台的存储系统。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    path: /nfsdata
    server: master

持久卷申领 (PersistentVolumeClaim, pVC）表达的是用广对存储的请求。概念上与 Pod 类似。Pod 会耗用节点资源，而 PVC申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式（例如，可以要求 PV 卷能够以 ReadWriteOnce、ReadOnly Many 或 ReadWritelany 模式之一来挂载，参见访问模式）。

尽管 PersistentVolumeClaim 允许用户消耗抽象的存储资源，常见的情况是针对不同的问题用户需要的是具有不同属性（如，性能）的PersistentVolume 卷。集群管理员需要能够提供不同性质的 PersistentVolume，并且这些 PV 卷之间的差别不仅限于卷大小和访问模式，同时又不能将卷是如何实现的这些细节暴露给用户。为了满足这类需求，就有了存储类 (StorageClass)源。

PVC持久化卷Claim

PersistentVolumeClaims

每个PVC 对象都有 spec 和status 部分，分别对应Claim的规约和状态。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

访问模式

Claim在请求具有特定访问模式的存储时，使用与卷相同的访问模式约定。

卷模式

Claim使用与卷相同的约定来表明是将卷作为文件系统还是块设备来使用。

资源

Claim和 Pod 一样，也可以请求特定数量的资源。在这个上下文中，请求的资源是存储。卷和Claim都使用相同的资源模型。

诜择算符

Claim可以设置标签选择算符来进一步过滤卷集合。只有标签与选择算符相匹配的卷能够鄉定到Claim上。选择算符包含两个

字段：

matchlabels- 卷必须包含带有此值的标签

matchExpressions-通过设定键（key）、值列表和操作符（operator）来构造的需求。合法的操作符有 In、Notin、Exists 和DoesNotExist.

来自 matchLabels 和matchExpressions 的所有需求都按逻辑与的方式组合在一起。这些需求都必须被满足才被视为匹配。

类

Claim可以通过为 storageClassNamne 属性设置 StorageClass 的名称来请求特定的存储类。只有所请求的类的PV卷，即storageClassName 值与 PVC 设置相同的 PV 卷，才能鄉定到 PVC Claim。

PVC Claimn 不必一定要请求某个类。如果 PVC 的storageClassName 属性值设置为w，则被视为要请求的是没有设置存储类的

PV 卷，因此这一 pVC Claim只能鄉定到未设置存储类的 PV 卷（末设置注解或者注解值为 w 的PersistentVolume (PV)对象在系统中不会被删除，因为这样做可能会引起数据丢失。未设置 storageClassName 的 PVC 与此大不相同，也会被集群作不同处理。具体筛查方式取決于 DefaultStorageClass 准入控制器插件是否被启用。

当某 PVC 除了请求 Storage Class 之外还设置了 selector，则这两种需求会按逻辑与关系处理：只有隶属于所请求类且带有所请求标签的 PV 才能绑定到 PVC。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}

存储类Storage Class

什么是Storage Class

Kubernetes提供了一套可以自动创建PV的机制，即：Dynamic Provisioning.而这个机制的核心在于：StorageClass这个API对象.

StorageClass对象会定义下面两部分内容：

Pv的属性.比如，存储类型,volume的大小等.
创建这种PV需要用到的存储插件

为什么需要StorageClass

在一个大规模的Kubernetes集群里，可能有成千上万个PVC,这就意味着运维人员必须实现创建出这个多个PV,此外，随着项目的需要，会有新的PVC不断被提交,那么运维人员就需要不断的添加新的,满足要求的PV,否则新的Pod就会因为PVC绑定不到PV而导致创建失败.而且通过 PVC 请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求

而且不同的应用程序对于存储性能的要求可能也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes 又为我们引入了一个新的资源对象：StorageClass，通过 StorageClass 的定义，管理员可以将存储资源定义为某种类型的资源，比如快速存储、慢速存储等，用户根据 StorageClass 的描述就可以非常直观的知道各种存储资源的具体特性了，这样就可以根据应用的特性去申请合适的存储资源了。

StorageClass 对象的命名很重要，用户使用这个命名来请求生成一个特定的类。当创建 StorageClass 对象时，管理员设置StorageClass 对象的命名和其他参数，一旦创建了对象就不能再对其更新。

管理员可以为没有申请鄉定到特定 StorageClass 的 PVC 指定一个默认的存储类：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: qgg-nfs-storage # 这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:
  archiveOnDelete: "false"