首页 > 其他分享> > K8S 的存储概念 PV、PVC、StorageClass

K8S 的存储概念 PV、PVC、StorageClass

2021-11-02 16:02:07 作者：互联网

文章目录

参考

PV、PVC、StorageClass讲解

简易版理解

Pod 的本地存储配置可以通过 hostpath 实现，但是远程存储或云存储，如何实现呢？这就涉及到了 PV、PVC、StorageClass
PV 持久化存储卷，用于描述或定义一个存储卷，一般由运维工程师创建

a. 静态 PV，工程师配置存储系统、存储类型、大小等

b. 动态分配，利用 StorageClass 进行分配，其相当于一个插件，利用镜像部署，与远程存储系统关联，需要 PV 时，进行自动创建
PVC 持久化存储卷声明，就是类似说我想要个什么样子（多大）的 PV，一般由开发工程师定义
StorageClass 存储类，用于动态创建，前面说 PV 由运维工程师创建，但集群量级变大时，手动创建来不及，因此利用此插件动态化创建，PVC 中声明想要使用的 StorageClass，就会创建相应的 PV，之后完成绑定
问题：为什么 PV 或 PVC 没有定义 storageClassName 字段，创建完成后却具有此字段？
- 答：是 DefaultStorageClassplugin插件设置的，若开启了此插件，并配置了默认 StorageClass，那么没有明确声明storageClassName 的 PV 和 PVC 将会被设置为此默认 StorageClass 的名称
StorageClass 的 volumeBindingMode: WaitForFirstConsumer 的作用是什么？
- 一般来说，创建 PVC 后，会自动与合适的 PV 关联，但 WaitForFirstConsume 此字段的意思是对于 PV, 即使有合适的 PVC 也不进行绑定，就是延迟绑定
- 对于动态创建来说，先创建 PVC，再动态创建 PV，进行绑定，之后挂载到 Pod 中，没什么问题
- 可是对于本地存储来说，一般是工程师先创建出 PV，但并不保证集群中每个节点都具有，因此需要将 Pod 调度到具有此 PV 的节点上，就是 Pod 的调度要考虑 PV 的分布
  - 所以延迟绑定的好处就是，新 Pod 中的 PVC 会自动寻找合适的 PV，从而调度到此节点上

hostpath

其实通过上面可以看出来，无论你使用什么类型的存储你都需要手动定义，指明存储类型以及相关配置。这里的hostpath类型还是比较简单的，如果是其他类型的比如分布式存储，那么这对开发人员来说将会是一种挑战，因为毕竟真正的存储是由存储管理员来设置的他们会更加了解，那么有没有一种方式让我们使用存储更加容易，对上层使用人员屏蔽底层细节呢？答案是肯定的，这就是PV、PVC的概念。不过需要注意的是我们在集群中通常不使用hostPath、emptyDir这种类型，除非你只是测试使用。

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - image: nginx
    name: mynginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: html
  volumes:
  - name: html # 名称
    hostPath: # 存储类型
      path: /data # 物理节点上的真实路径
      type: Directory # 如果该路径不存在讲如何处理，Directory是要求目录必须存在

PV

PV全称叫做Persistent Volume，持久化存储卷。它是用来描述或者说用来定义一个存储卷的，这个通常都是有运维或者数据存储工程师来定义。比如下面我们定义一个NFS类型的PV：

apiVersion: v1
kind: PersistentVolume
metadata:  # PV建立不要加名称空间，因为PV属于集群级别的
  name: nfs-pv001  # PV名称
  labels: # 这些labels可以不定义
    name: nfs-pv001
    storetype: nfs
spec:  # 这里的spec和volumes里面的一样
  storageClassName: normal  # 这个本来没有设置，其实是DefaultStorageClassplugin插件设置的，将默认 StroageClass 绑定到 没有定义此字段的 PV 或 PVC 中
  accessModes:  # 设置访问模型
    - ReadWriteMany
    - ReadWriteOnce
    - ReadOnlyMany
  capacity: # 设置存储空间大小
    storage: 500Mi
  persistentVolumeReclaimPolicy: Retain # 回收策略
  nfs:
    path: /work/volumes/v1
    server: stroagesrv01.contoso.com

accessModes：支持三种类型

ReadWriteMany 多路读写，卷能被集群多个节点挂载并读写
ReadWriteOnce 单路读写，卷只能被单一集群节点挂载读写
ReadOnlyMany 多路只读，卷能被多个集群节点挂载且只能读

这里的访问模型总共有三种，但是不同的存储类型支持的访问模型不同，具体支持什么需要查询官网。比如我们这里使用nfs，它支持全部三种。但是ISCI就不支持ReadWriteMany；HostPath就不支持ReadOnlyMany和ReadWriteMany。

persistentVolumeReclaimPolicy：也有三种策略，这个策略是当与之关联的PVC被删除以后，这个PV中的数据如何被处理

Retain 当删除与之绑定的PVC时候，这个PV被标记为released（PVC与PV解绑但还没有执行回收策略）且之前的数据依然保存在该PV上，但是该PV不可用，需要手动来处理这些数据并删除该PV。
Delete 当删除与之绑定的PVC时候
Recycle 这个在1.14版本中以及被废弃，取而代之的是推荐使用动态存储供给策略，它的功能是当删除与该PV关联的PVC时，自动删除该PV中的所有数据

注意：PV必须先与POD创建，而且只能是网络存储不能属于任何Node，虽然它支持HostPath类型但由于你不知道POD会被调度到哪个Node上，所以你要定义HostPath类型的PV就要保证所有节点都要有HostPath中指定的路径

PVC

PVC是用来描述希望使用什么样的或者说是满足什么条件的存储，它的全称是Persistent Volume Claim，也就是持久化存储声明。开发人员使用这个来描述该容器需要一个什么存储。比如下面使用NFS的PVC：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc001
  namespace: default
  labels: # 这些labels可以不定义
    name: nfs-pvc001
    storetype: nfs
    capacity: 500Mi
spec:
  storageClassName: normal # 若开启一个的叫做DefaultStorageClassplugin插件，就会默认有这样一个存储类，它会自动添加到你的任何没有明确声明storageClassName的PV和PVC中。 这个是静态绑定  实际上并没有调用 storageClass进行动态分配
  accessModes:  # PVC也需要定义访问模式，不过它的模式一定是和现有PV相同或者是它的子集，否则匹配不到PV
  - ReadWriteMany
  resources: # 定义资源要求PV满足这个PVC的要求才会被匹配到
    requests:
      storage: 500Mi  # 定义要求有多大空间

Pod 中使用 PVC

这里通过volumes来声明使用哪个PVC，可以看到和自己定义持久化卷类似，但是这里更加简单了，直接使用PVC的名字即可。在容器中使用/data目录就会把数据写入到NFS服务器上的目录中。

当我们删除那个PVC的时候，该PV变成Released状态，由于我们的策略是Retain，所以如果想让这个PV变为可用我们就需要手动清理数据并删除这个PV。这里你可能会觉得矛盾，你让这个PV变为可用，为什么还要删除这个PV呢？其实所谓可用就是删除这个PV然后建立一个同名的。

可以看出来PVC就相当于是容器和PV之间的一个接口，使用人员只需要和PVC打交道即可。另外你可能也会想到如果当前环境中没有合适的PV和我的PVC绑定，那么我创建的POD不就失败了么？的确是这样的，不过如果发现这个问题，那么就赶快创建一个合适的PV，那么这时候持久化存储循环控制器会不断的检查PVC和PV，当发现有合适的可以绑定之后它会自动给你绑定上然后被挂起的POD就会自动启动，而不需要你重建POD。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tomcat-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      appname: myapp
  template:
    metadata:
      name: myapp
      labels:
        appname: myapp
    spec:
      containers:
      - name: myapp
        image: tomcat:8.5.38-jre8
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        volumeMounts:
          - name: tomcatedata
            mountPath : "/data"
      volumes:
        - name: tomcatedata
          persistentVolumeClaim:
            claimName: nfs-pvc001

StorageClass

PV是运维人员来创建的，开发操作PVC，可是大规模集群中可能会有很多PV，如果这些PV都需要运维手动来处理这也是一件很繁琐的事情，所以就有了动态供给概念，也就是Dynamic Provisioning。而我们上面的创建的PV都是静态供给方式，也就是Static Provisioning。而动态供给的关键就是StorageClass，它的作用就是创建PV模板。

创建StorageClass里面需要定义PV属性比如存储类型、大小等；另外创建这种PV需要用到存储插件。最终效果是，用户提交PVC，里面指定存储类型，如果符合我们定义的StorageClass，则会为其自动创建PV并进行绑定。

基于这种形式，我们只需要根据我们有的存储系统来定义StorageClass，通过名称来标识不同种类的存储，比如SSD、block-device这种名称，而不需要定义具体大小。那么使用人员就可以根据需要通过StorageClass的名字来使用，从而实现动态创建PV的过程。

这里有个要求就是你的存储系统需要提供某种接口来让controller可以调用并传递进去PVC的参数去创建PV，很多云存储都支持。可是也有不支持的，比如NFS就不支持所以我们需要一个单独的插件来完成这个工作。也就是例子中使用的quay.io/external_storage/nfs-client-provisioner镜像，但是创建PV也需要相关权限，也就是例子中rabc.yaml部分。在定义StorageClass中有一个叫做provisioner: fuseim.pri/ifs这个就是插件的名称，这个名称其实也就是官方例子中deployment中设置的名字，这个名字你可以修改。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/aws-ebs  # 存储插件名称 进行动态创建 PV
parameters:
  type: io1
  iopsPerGB: "10"
  fsType: ext4

本地存储的 StorageClass

简言之，本地存储，是 PV 创建在宿主机上，同时要求 PV 先创建，但同时要考虑一个问题？就是集群中有些节点有此 PV，有些节点没有，因此要将 Pod 调度到有此 PV 的节点上，就是 Pod 调度要考虑 PV 的分布。

那么如何考虑 PV 的分布呢？答案：靠 StorageClass 的 volumeBindingMode: WaitForFirstConsumer

此字段的意思延迟绑定，就是即使有符合条件的 PVC，也不能与此 PV 绑定，因此 Pod 调度到别的节点上就没法运行了

所以 Pod 调度就会考虑他所需的 PV 也就是 LPV（Local Persistent Volume）在哪，然后调度到相应的节点上，创建 PVC 的绑定，最后挂在到 Pod 中

本地持久化存储（Local Persistent Volume）就是把数据存储在POD运行的宿主机上，我们知道宿主机有hostPath和emptyDir，由于这两种的特定不适用于本地持久化存储。那么本地持久化存储必须能保证POD被调度到具有本地持久化存储的节点上。

为什么需要这种类型的存储呢？有时候你的应用对磁盘IO有很高的要求，网络存储性能肯定不如本地的高，尤其是本地使用了SSD这种磁盘。

但这里有个问题，通常我们先创建PV，然后创建PVC，这时候如果两者匹配那么系统会自动进行绑定；哪怕是动态PV创建，也是先调度POD到任意一个节点，然后根据PVC来进行创建PV然后进行绑定最后挂载到POD中；可是本地持久化存储有一个问题就是这种PV必须要先准备好，而且不一定集群所有节点都有这种PV，如果POD随意调度肯定不行，如何保证POD一定会被调度到有PV的节点上呢？这时候就需要在PV中声明节点亲和，且POD被调度的时候还要考虑卷的分布情况。

这里的volumeBindingMode: WaitForFirstConsumer很关键，意思就是延迟绑定，当有符合PVC要求的PV不立即绑定。因为POD使用PVC，而绑定之后，POD被调度到其他节点，显然其他节点很有可能没有那个PV所以POD就挂起了，另外就算该节点有合适的PV，而POD被设置成不能运行在该节点，这时候就没法了，延迟绑定的好处是，POD的调度要参考卷的分布。当开始调度POD的时候看看它要求的LPV在哪里，然后就调度到该节点，然后进行PVC的绑定，最后在挂载到POD中，这样就保证了POD所在的节点就一定是LPV（Local PV）所在的节点。所以让PVC延迟绑定，就是等到使用这个PVC的POD出现在调度器上之后（真正被调度之前），然后根据综合评估再来绑定这个PVC。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer # 很关键 延迟绑定  Pod 的调度要参考卷PV的分布
-------
# 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage  # 与上面 StorageClass 名称匹配
  local: # local类型
    path: /data/vol1  # 节点上的具体路径
  nodeAffinity: # 这里就设置了节点亲和
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node01 # 这里我们使用node01节点，该节点有/data/vol1路径

宿主机是如何挂载远程目录的

挂载过程会有不同，这取决于远程存储的类型，它是块设备存储还是文件设备存储。但是不管怎么样POD有这样一个目录/var/lib/kubelet/pods/<Pod 的 ID>/volumes/kubernetes.io~<Volume 类型 >/<Volume 名字 >这个目录是POD被调度到该节点之后，由kubelet为POD创建的。因为它一定会被创建，因为系统中的默认secret就会被挂载到这里。之后就要根据存储设备类型的不同做不同处理。

文件存储设备

以nfs这种文件设备存储来说,由于创建了必要的目录，那么kubelet就直接使用mount命令把nfs目录挂载到这个目录上volumes/kubernetes.io~<type>/<Volume 名字>，注意这时候仅仅是把这个远程存储挂载到宿主机目录上，要想让容器使用还需要做调用相关接口来把这个宿主机上的目录挂载到容器上。所以当准备好之后启动容器的时候就是利用CRI里的mounts参数把这个宿主机的目录挂载到容器中指定的目录上，就相当于执行docker run -v。

块存储设备

块存储设备你可以理解为一个磁盘。这个的处理要稍微复杂一点，就好像你为Linux服务器添加一块磁盘一样，你得先安装然后分区格式化之后挂载到某个目录使用。

/var/lib/kubelet/pods/<Pod 的 ID>/volumes/kubernetes.io~<Volume 类型 >/<Volume 名字 >这个目录依然会创建。当POD被调度到该节点上会做如下操作:

首先要安装一个块设备存储到宿主机（不是物理安装，而是通过API来安装），如何安装取决于不同块存储设备的API，很多云厂商有这种块存储设备比如Google的GCE。
格式化磁盘，
把格式化好的磁盘设备挂载到宿主机上的目录
启动容器挂载宿主机上的目录到容器中

相对于文件设备存储来说块设备要稍微复杂一点，不过上面这些过程都是自动的有kubelet来完成。

小结

负责把PVC绑定到PV的是一个持久化存储卷控制循环，这个控制器也是kube-manager-controller的一部分运行在master上。而真正把目录挂载到容器上的操作是在POD所在主机上发生的，所以通过kubelet来完成。而且创建PV以及PVC的绑定是在POD被调度到某一节点之后进行的，完成这些操作，POD就可以运行了。下面梳理一下挂载一个PV的过程：

用户提交一个包含PVC的POD
调度器把根据各种调度算法把该POD分配到某个节点，比如node01
Node01上的kubelet等待Volume Manager准备存储设备
PV控制器调用存储插件创建PV并与PVC进行绑定
Attach/Detach Controller或Volume Manager通过存储插件实现设备的attach。（这一步是针对块设备存储）
Volume Manager等待存储设备变为可用后，挂载该设备到/var/lib/kubelet/pods/<Pod 的 ID>/volumes/kubernetes.io~<Volume 类型 >/<Volume 名字 >目录上
Kubelet被告知卷已经准备好，开始启动POD，通过映射方式挂载到容器中

StorageClass总结：本地卷也就是LPV不支持动态供给的方式，延迟绑定，就是为了综合考虑所有因素再进行POD调度。其根本原因是动态供给是先调度POD到节点，然后动态创建PV以及绑定PVC最后运行POD；而LPV是先创建与某一节点关联的PV，然后在调度的时候综合考虑各种因素而且要包括PV在哪个节点，然后再进行调度，到达该节点后在进行PVC的绑定。也就说动态供给不考虑节点，LPV必须考虑节点。所以这两种机制有冲突导致无法在动态供给策略下使用LPV。换句话说动态供给是PV跟着POD走，而LPV是POD跟着PV走。

标签：存储,PV,绑定,PVC,StorageClass,POD,节点
来源： https://blog.csdn.net/qq_24433609/article/details/121102137