k8s之PV以及PVC

Posted 2022-04-18 爱上口袋的天空

一、简介

        在我们整个k8s集群中，外部可能有有一些存储的资源，比如说nfs，mfs，iscsi块存储，这些存储都是由我们的存储工程师去创建的，k8s工程师想要直接去使用他们的话，肯定是很不方便的，因为不同的存储方式不一样。在k8s中，给我们提供了一个新的对象资源，叫做PV，不同的PV会对应到不用的存储资源，这样我们在部署pod的时候直接调用集群内部的pv，即可完成对存储资源的使用，但是呢，直接调用PV的话，有个问题就是，这个pv是否满足我们的需求，因为我们可能需要的是存储能力比较大存储资源，所以这个时候需要一个一个去对比pv，这样很耗费资源，这个时候又引入了我们的pvc。我们在创建pod的时候会附带一个PVC的请求，PVC的请求相当于就是去寻找一个合适的pv，进行绑定，这样我们的pod就会使用到这个pv了。也就是说让我们的pvc去寻找pv，而不是我们的pod资源去寻找。

---

二、概念

1、PersistentVolume （PV）

        是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期（pod被删除了，我们的PV依然会被保留，类似于卷）。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统。

2、PersistentVolumeClaim （PVC）

        PVC 的全称是PersistentVolumeClaim（持久化卷声明），PVC 是用户存储的一种声明，PVC 和 Pod 比较类似，Pod 消耗的是节点，PVC 消耗的是 PV 资源，Pod 可以请求 CPU 和内存，而 PVC 可以请求特定的存储空间和访问模式，例如，可以以读/写一次或 只读多次模式挂载。对于真正使用存储的用户不需要关心底层的存储实现细节，只需要直接使用 PVC 即可。也就是我们集群中会有一个个的PV，可以被直接挂在到某个pod，也可以被PVC绑定，然后挂载到某个pod。

3、静态 pv

        集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中，可用于消费。

4、动态PV

        当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时，集群可能会尝试动态地为 PVC 创建卷。此配置基于 StorageClasses ：PVC 必须请求 [存储类]，并且管理员必须创建并配置该类才能进行动态创建。声明该类为 "" 可以有效地禁用其动态配置。

        要启用基于存储级别的动态存储配置，集群管理员需要启用 API server 上的DefaultStorageClass [准入控制器]。例如，通过确保 DefaultStorageClass 位于 API server 组件的 --admission-control 标志，使用逗号分隔的有序值列表中，可以完成此操作。

5、绑定PV

        master 中的控制环路监视新的 PVC，寻找匹配的 PV（如果可能），并将它们绑定在一起。如果为新的 PVC 动态调配 PV，则该环路将始终将该 PV 绑定到 PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量。一旦 PV 和 PVC 绑定后， PersistentVolumeClaim 绑定是排他性的，不管它们是如何绑定的，PVC 跟PV 绑定是一对一的映射。

6、持久化卷声明的保护

        PVC 保护的目的是确保由 pod 正在使用的 PVC 不会从系统中移除，因为如果被移除的话可能会导致数据丢失。意思就是我们的PV被我们的PVC绑定的时候，某一天我们的pod被删除之后，这个PVC依然会存在我们的系统之中，并且这个PVC依然会跟我们的PV有一个绑定关系，主要是为了防止我们的pod出现丢失之后，PVC被删除了，数据就会丢失，这个肯定是合理的。

        当启用PVC 保护 alpha 功能时，如果用户删除了一个 pod 正在使用的 PVC，则该 PVC 不会被立即删除。PVC 的删除将被推迟，直到 PVC 不再被任何 pod 使用。

7、访问模式

        PersistentVolume 卷可以用资源提供者所支持的任何方式挂载到宿主系统上。 如下表所示，提供者（驱动）的能力不同，每个 PV 卷的访问模式都会设置为 对应卷所支持的模式值。 例如，NFS 可以支持多个读写客户，但是某个特定的 NFS PV 卷可能在服务器 上以只读的方式导出。每个 PV 卷都会获得自身的访问模式集合，描述的是 特定 PV 卷的能力

 在命令行接口（CLI）中，访问模式也使用以下缩写形式：

• RWO - ReadWriteOnce
• ROX - ReadOnlyMany
• RWX - ReadWriteMany
• RWOP - ReadWriteOncePod

8、PVC 状态

• Available（可用）——一块空闲资源还没有被任何声明绑定
• Bound（已绑定）——卷已经被声明绑定
• Released（已释放）——声明被删除，但是资源还未被集群重新声明
• Failed（失败）——该卷的自动回收失败

---

三、下面我们定义pv资源

1、首先在我们事先安装的nfs目录下创建几个目录

#nfs主节点
mkdir -p /nfs/data/01
mkdir -p /nfs/data/02
mkdir -p /nfs/data/03

2、定义PV，文件名为pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv01-10m #自定义pv名字
spec:
  capacity:
    storage: 10M #定义这个pv的限制存储大小
  accessModes:
    - ReadWriteMany #定义操作的权限
  storageClassName: nfs #自定义定义存储的类名,特定类的PV只能绑定到请求该类的PVC。没有storageClassName的PV没有类，只能绑定到不请求特定类的PVC
  nfs:
    path: /nfs/data/01 #绑定主机的的路径
    server: 192.168.0.164 #指定nfs主机的ip地址
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv02-1gi #自定义pv名字
spec:
  capacity:
    storage: 1Gi #定义这个pv的限制存储大小
  accessModes:
    - ReadWriteMany #定义操作的权限
  storageClassName: nfs #自定义定义存储的类名,特定类的PV只能绑定到请求该类的PVC。没有storageClassName的PV没有类，只能绑定到不请求特定类的PVC
  nfs:
    path: /nfs/data/02 #绑定主机的的路径
    server: 192.168.0.164 #指定nfs主机的ip地址
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv03-3gi #自定义pv名字
spec:
  capacity:
    storage: 3Gi #定义这个pv的限制存储大小
  accessModes:
    - ReadWriteMany #定义操作的权限
  storageClassName: nfs #自定义定义存储的类名,特定类的PV只能绑定到请求该类的PVC。没有storageClassName的PV没有类，只能绑定到不请求特定类的PVC
  nfs:
    path: /nfs/data/03 #绑定主机的的路径
    server: 192.168.0.164 #指定nfs主机的ip地址

执行pv脚本：

3、定义PVC,名称pvc.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nginx-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 200Mi #定义要申请的空间大小
  storageClassName: nfs #这里要和我们定义pv那里storageClassName一样才行

 执行pvc文件：

kubectl apply -f pvc.yaml

查看pv:

 由上面可以发现绑定了一个1G大小的pv资源,因为没有200M大小的PV

---

四、下面我们创建一个Deployment去绑定pvc资源

1、创建Deployment资源去绑定上面我们定义的pvc

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deploy-pvc
  name: nginx-deploy-pvc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-deploy-pvc
  template:
    metadata:
      labels:
        app: nginx-deploy-pvc
    spec:
      containers:
      - image: nginx
        name: nginx
        volumeMounts: #这里定义pod中要挂载的路径
        - name: html
          mountPath: /usr/share/nginx/html
      volumes:
        - name: html #和上面的挂载目录一致
          persistentVolumeClaim:
            claimName: nginx-pvc #这里要绑定我们创建的pvc

2、执行上面的脚本

可以看到正在启动：

 启动ok了，

 3、下面我们在pvc挂载的目录下创建测试文件

上面我们创建了一个index.html文件，里面内容为test pvc，下面我们到创建的pod中查看同步结果：

 

 由上可以发现已经同步了