Kubernetes

Kubernetes之十四----PV和PVC详解

本文主要是介绍Kubernetes之十四----PV和PVC详解，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

认识PV/PVC/StorageClass

1.1 介绍

　　管理存储是管理计算的一个明显问题。该PersistentVolume子系统为用户和管理员提供了一个API，用于抽象如何根据消费方式提供存储的详细信息。为此，我们引入了两个新的API资源：PersistentVolume和PersistentVolumeClaim

　　PersistentVolume（PV）是集群中由管理员配置的一段网络存储。 它是集群中的资源，就像节点是集群资源一样。 PV是容量插件，如Volumes，但其生命周期独立于使用PV的任何单个pod。 此API对象捕获存储实现的详细信息，包括NFS，iSCSI或特定于云提供程序的存储系统。

　　PersistentVolumeClaim（PVC）是由用户进行存储的请求。 它类似于pod。 Pod消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（例如，可以一次读/写或多次只读）。

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

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

　　PVC和PV是一一对应的。

 

1.2 生命周期

　　PV是群集中的资源。PVC是对这些资源的请求，并且还充当对资源的检查。PV和PVC之间的相互作用遵循以下生命周期：

Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling

  •  供应准备Provisioning---通过集群外的存储系统或者云平台来提供存储持久化支持。
    •  - 静态提供Static：集群管理员创建多个PV。 它们携带可供集群用户使用的真实存储的详细信息。 它们存在于Kubernetes API中，可用于消费
    •  - 动态提供Dynamic：当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时，集群可能会尝试为PVC动态配置卷。 此配置基于StorageClasses：PVC必须请求一个类，并且管理员必须已创建并配置该类才能进行动态配置。 要求该类的声明有效地为自己禁用动态配置。
  •  绑定Binding---用户创建pvc并指定需要的资源和访问模式。在找到可用pv之前，pvc会保持未绑定状态。
  •  使用Using---用户可在pod中像volume一样使用pvc。
  •  释放Releasing---用户删除pvc来回收存储资源，pv将变成“released”状态。由于还保留着之前的数据，这些数据需要根据不同的策略来处理，否则这些存储资源无法被其他pvc使用。
  •  回收Recycling---pv可以设置三种回收策略：保留（Retain），回收（Recycle）和删除（Delete）。
    •  - 保留策略：允许人工处理保留的数据。
    •  - 删除策略：将删除pv和外部关联的存储资源，需要插件支持。
    •  - 回收策略：将执行清除操作，之后可以被新的pvc使用，需要插件支持。

 注：目前只有NFS和HostPath类型卷支持回收策略，AWS EBS,GCE PD,Azure Disk和Cinder支持删除(Delete)策略。

 

1.3 PV类型

  •  GCEPersistentDisk
  •  AWSElasticBlockStore
  •  AzureFile
  •  AzureDisk
  •  FC (Fibre Channel)
  •  Flexvolume
  •  Flocker
  •  NFS
  •  iSCSI
  •  RBD (Ceph Block Device)
  •  CephFS
  •  Cinder (OpenStack block storage)
  •  Glusterfs
  •  VsphereVolume
  •  Quobyte Volumes
  •  HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
  •  Portworx Volumes
  •  ScaleIO Volumes
  •  StorageOS

 

1.4 PV卷阶段状态

  •  Available – 资源尚未被claim使用
  •  Bound – 卷已经被绑定到claim了
  •  Released – claim被删除，卷处于释放状态，但未被集群回收。
  •  Failed – 卷自动回收失败

 

1.5 存储绑定 

用户基于一系列存储需求和访问模式定义好 PVC 后， Kubernetes 系统的控制器即会为 其查找匹配的 PV，并于找到之后在此二者之间建立起关联关系，而后它们二者之间的状态 即转为“绑定”（Binding）。 若 PV 是为 PVC 而动态创建的 ， 则该 PY 专用于其 PVC。 若是无法为 PVC 找到可匹配的 PY，则 PVC 将一直处于未绑定（ unbound）状态，直到 有符合条件的 PV 出现并完成绑定方才可用。

( 1 ）存储使用（Using) Pod 资源基于 p巳rsistenVolumeClaim 卷类型的定义，将选定的 PVC 关联为存储卷，而 后即可为内部的容器所使用。 对于支持多种访问模式的存储卷来说，用户需要额外指定要使 用的模式。一旦完成将存储卷挂载至 Pod 对象内的容器中，其应用即可使用关联的 PV 提供 的存储空间。

( 2 ) PVC 保护（Protection) 为了避免使用中的存储卷被移除而导致数据丢失， Kubernetes 自 1.9 版本起引入了 “ PVC 保护机制” 。 启用了此特性后，万一有用户删除了仍处于某 Pod 资源使用中的 PVC 时， Kubernetes 不会立即予以移除，而是推迟到不再被任何 Pod 资源使用后方才执行删除操 作。 处于此种阶段的 PVC 资源的 status 宇段为“ Termination ” ，并且其 Finalizers 字段中包 含“ kubernetes.io/pvc-protection” 。

 

1.6 PVC 保护（Protection) 

为了避免使用中的存储卷被移除而导致数据丢失，启用了此特性后，万一有用户删除了仍处于某 Pod 资源使用中的 PVC 时， Kubernetes 不会立即予以移除，而是推迟到不再被任何 Pod 资源使用后方才执行删除操 作。 处于此种阶段的 PVC 资源的 status 宇段为“ Termination ” ，并且其 Finalizers 字段中包 含“ kubernetes.io/pvc-protection” 。

1.7 存储回收（ Reclaiming) 

完成存储卷的使用目标之后， 即可删除 PVC 对象以便进行资源回收。 不过，至于如 何操作则取决于 PV 的回收策略。 目 前，可用的回收策略有三种 ： R巳tained、 Recycled 和
Deleted。

( 1 ）留存（Retain ) 

留存策略意味着在删除 PVC 之后， Kubernetes 系统不会自动删除 PY ，而仅仅是将 它置于“释放”（released）状态。 不过，此种状态的 PV 尚且不能被其他 PVC 申请所绑定， 因为此前的申请生成的数据仍然存在，需要由管理员于动决定其后续处理方案。 这就 意味着，如果想要再次使用此类的 PV 资源 ，则需要由管理员按下面的步骤手动执行删除 操作。

  • 删除 PV，这之后，此 PY 的数据依然留存于外部的存储之上。
  • 手工清理存储系统上依然留存的数据。
  • 手工删除存储系统级的存储卷（例如， RBD 存储系统上的 image）以释放空间，以 便再次创建，或者直接将其重新创建为 PV。

( 2 ）回收（Recycle)

如果可被底层存储插件支持，资源回收策略会在存储卷上执行数据删除操作并让 PV 资师、再次变为可被 Claim。 另外，管理员也可以配置一个自定义的回收器 Pod 模板，以便执行 自定义的回收操作。 不过，此种回收策略行将废弃。 

( 3 ）删除（Delete)

对于支持 Deleted 回收策略的存储插件来说，在 PVC 被删除后会直接移除 PV 对象，同 时移除的还有 PY 相关的外部存储系统上的存储资产（ asset）。 支持这种操作的存储系统有 AWS EBS , GCE PD 、 Azure Disk 或 Cinder。 动态创建的 PV 资源的回收策略取决于相关存 储类上的定义，存储类上相关的默认策略为 Delete ，大多数情况下，管理员都需要按用户期 望的处理机制修改此默认策略 ，以免导致数据非计划内的误删除。

2、创建PV

2.1 准备nfs服务

（1）在nfs服务器上先建立存储卷对应的目录

1 2 3 4 5 6 7 8 9 [root@nfs ~]# cd /data/volumes/ [root@nfs volumes]# mkdir v{1,2,3,4,5} [root@nfs volumes]# ls index.html  v1  v2  v3  v4  v5 [root@nfs volumes]# echo "<h1>NFS stor 01</h1>" > v1/index.html [root@nfs volumes]# echo "<h1>NFS stor 02</h1>" > v2/index.html [root@nfs volumes]# echo "<h1>NFS stor 03</h1>" > v3/index.html [root@nfs volumes]# echo "<h1>NFS stor 04</h1>" > v4/index.html [root@nfs volumes]# echo "<h1>NFS stor 05</h1>" > v5/index.html

　　

（2）修改nfs的配置

1 2 3 4 5 6 [root@nfs volumes]# vim /etc/exports /data/volumes/v1        192.168.130.0/24(rw,no_root_squash) /data/volumes/v2        192.168.130.0/24(rw,no_root_squash) /data/volumes/v3        192.168.130.0/24(rw,no_root_squash) /data/volumes/v4        192.168.130.0/24(rw,no_root_squash) /data/volumes/v5        192.168.130.0/24(rw,no_root_squash)

　　

（3）查看nfs的配置

1 2 3 4 5 6 [root@nfs volumes]# exportfs -arv exporting 192.168.130.0/24:/data/volumes/v5 exporting 192.168.130.0/24:/data/volumes/v4 exporting 192.168.130.0/24:/data/volumes/v3 exporting 192.168.130.0/24:/data/volumes/v2 exporting 192.168.130.0/24:/data/volumes/v1

　　

（4）使配置生效

1 2 3 4 5 6 7 [root@nfs volumes]# showmount -e Export list for nfs: /data/volumes/v5 192.168.7.0/24 /data/volumes/v4 192.168.7.0/24 /data/volumes/v3 192.168.7.0/24 /data/volumes/v2 192.168.7.0/24 /data/volumes/v1 192.168.7.0/24

　

（5）启动nfs服务器

# systemctl start nfs

　　

2.2 在master上创建PV

（1）编写yaml文件，并创建pv

创建5个pv，存储大小各不相同，是否可读也不相同

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 [root@master volumes]# vim pv-damo.yaml apiVersion: v1 kind: PersistentVolume metadata:   name: pv001   labels:     name: pv001 spec:   nfs:     path: /data/volumes/v1     server: nfs   accessModes: ["ReadWriteMany","ReadWriteOnce"]   capacity:     storage: 2Gi  # 指定多大的内存 --- apiVersion: v1 kind: PersistentVolume metadata:   name: pv002   labels:     name: pv002 spec:   nfs:     path: /data/volumes/v2     server: nfs   accessModes: ["ReadWriteOnce"]   capacity:     storage: 5Gi --- apiVersion: v1 kind: PersistentVolume metadata:   name: pv003   labels:     name: pv003 spec:   nfs:     path: /data/volumes/v3     server: nfs   accessModes: ["ReadWriteMany","ReadWriteOnce"]   capacity:     storage: 20Gi --- apiVersion: v1 kind: PersistentVolume metadata:   name: pv004   labels:     name: pv004 spec:   nfs:     path: /data/volumes/v4     server: nfs   accessModes: ["ReadWriteMany","ReadWriteOnce"]   capacity:     storage: 10Gi --- apiVersion: v1 kind: PersistentVolume metadata:   name: pv005   labels:     name: pv005 spec:   nfs:     path: /data/volumes/v5     server: nfs   accessModes: ["ReadWriteMany","ReadWriteOnce"]   capacity:     storage: 15Gi [root@master volumes]# kubectl apply -f pv-damo.yaml persistentvolume/pv001 created persistentvolume/pv002 created persistentvolume/pv003 created persistentvolume/pv004 created persistentvolume/pv005 created

　　

（2）查询验证

1 2 3 4 5 6 7 [root@master ~]# kubectl get pv NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE pv001     5Gi        RWO,RWX        Retain           Available                                      9s pv002     5Gi        RWO            Retain           Available                                      9s pv003     5Gi        RWO,RWX        Retain           Available                                      9s pv004     10Gi       RWO,RWX        Retain           Available                                      9s pv005     15Gi       RWO,RWX        Retain           Available                                      9s

　　

3、创建PVC，绑定PV

（1）编写yaml文件，并创建pvc

创建一个pvc，需要6G存储；所以不会匹配pv001、pv002、pv003

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [root@master volumes]# vim vol-pvc-demo.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata:   name: mypvc   namespace: default spec:   accessModes: ["ReadWriteMany"]   resources:     requests:       storage: 6Gi  # 指定多大的内存 --- apiVersion: v1 kind: Pod metadata:   name: vol-pvc   namespace: default spec:   volumes:   - name: html     persistentVolumeClaim:       claimName: mypvc   containers:   - name: myapp     image: ikubernetes/myapp:v1     volumeMounts:     - name: html       mountPath: /usr/share/nginx/html/ [root@master volumes]# kubectl apply -f vol-pvc-demo.yaml persistentvolumeclaim/mypvc created pod/vol-pvc created

　　

（2）查询验证：pvc已经绑定到pv004上

1 2 3 4 5 6 7 8 9 10 [root@master ~]# kubectl get pvc NAME      STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE mypvc     Bound     pv004     10Gi       RWO,RWX                       24s [root@master ~]# kubectl get pv NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON    AGE pv001     5Gi        RWO,RWX        Retain           Available                                            1m pv002     5Gi        RWO            Retain           Available                                            1m pv003     5Gi        RWO,RWX        Retain           Available                                            1m pv004     10Gi       RWO,RWX        Retain           Bound       default/mypvc # 绑定到pv4上                            1m pv005     15Gi       RWO,RWX        Retain           Available                                            1m

　　

（3）查询业务验证

[root@master ~]# kubectl get pods -o wide
NAME      READY     STATUS    RESTARTS   AGE       IP             NODE
vol-pvc   1/1       Running   0          59s       10.244.2.117   node2
[root@master ~]# curl 10.244.2.117
<h1>NFS stor 04</h1>

　　

4、删除Pod、PVC、PV

1、此时我们如果想删除PVC，就必须先删除Pod才能删除PVC，因为PVC有受保护机制，无法直接删除。

[root@master ~]# kubectl get pvc   # 查看此时的PVC名称
NAME    STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mypvc   Bound    pv004    10Gi       RWO,RWX                       14m
[root@master ~]# kubectl delete pvc mypvc   #删除PVC，此时是受保护状态，无法删除
persistentvolumeclaim "mypvc" deleted

 

2、开启新的k8s-master窗口删除Pod，此时上面执行删除PVC的操作也会被执行

[root@master ~]# kubectl get pods    # 查看此时的pod名称
NAME      READY   STATUS    RESTARTS   AGE
vol-pvc   1/1     Running   0          17m
[root@master ~]# kubectl delete pod vol-pvc   # 删除对应的pod
pod "vol-pvc" deleted

#########此时查看上面删除PVC的操作也被执行了
[root@master ~]# kubectl delete pvc mypvc 
persistentvolumeclaim "mypvc" deleted

 

3、删除完PVC后，此时PV就处于释放空闲状态

[root@master ~]# kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON   AGE
pv001   2Gi        RWO,RWX        Retain           Available                                           24m
pv002   5Gi        RWO            Retain           Available                                           24m
pv003   20Gi       RWO,RWX        Retain           Available                                           24m
pv004   10Gi       RWO,RWX        Retain           Released    default/mypvc                           24m
pv005   15Gi       RWO,RWX        Retain           Available                                           24m

 

4、如果此时知道PV不再使用，也可以将PV删除，最后将在NFS服务器上共享的文件也一并删除，如果不确定文件是否还使用，可以将共享的文件先移动到其他目录，以防再次使用

[root@master ~]# kubectl delete pv pv004  # 删除PV
persistentvolume "pv004" deleted


########此时我们在NFS共享服务器的指定目录下，将对应的共享文件移动到指定目录下，进行备份
[root@mon03volumes]#cd v4
[root@mon03v4]#pwd
/data/volumes/v4
[root@mon03v4]#ll
total 4
-rw-r--r-- 1 root root 21 Aug 2 22:13 index.html
[root@mon03v4]#rm -rf ./*   # 如果文件还在使用，最好是移动到其他目录进行备份

　　

 

这篇关于Kubernetes之十四----PV和PVC详解的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！
您可能喜欢
栏目导航