书籍来源：cloudman《每天5分钟玩转Kubernetes》

一边学习一边整理老师的课程内容及试验笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：每天5分钟玩转Kubernetes | 汇总_COCOgsta的博客-CSDN博客

Volume提供了非常好的数据持久化方案，不过在可管理性上还有不足。

拿前面的AWS EBS例子来说，要使用Volume，Pod必须事先知道如下信息：

（1）当前Volume来自AWS EBS。

（2）EBS Volume已经提前创建，并且知道确切的volume-

Pod通常是由应用的开发人员维护，而Volume则通常是由存储系统的管理员维护。开发人员要获得上面的信息，要么询问管理员，要么自己就是管理员。

这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境，这样的情况还可以接受，当集群规模变大，特别是对于生成环境，考虑到效率和安全性，这就成了必须要解决的问题。

Kubernetes给出的解决方案是PersistentVolume和PersistentVolumeClaim。

PersistentVolume（PV）是外部存储系统中的一块存储空间，由管理员创建和维护。与Volume一样，PV具有持久性，生命周期独立于Pod。

PersistentVolumeClaim（PVC）是对PV的申请（Claim）。PVC通常由普通用户创建和维护。需要为Pod分配存储资源时，用户可以创建一个PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes会查找并提供满足条件的PV。

有了PersistentVolumeClaim，用户只需要告诉Kubernetes需要什么样的存储资源，而不必关心真正的空间从哪里分配、如何访问等底层细节信息。这些Storage Provider的底层信息交给管理员来处理，只有管理员才应该关心创建PersistentVolume的细节信息。

Kubernetes支持多种类型的PersistentVolume，比如AWS EBS、Ceph、NFS等，完整列表请参考
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of- persistent-volumes。

下面我们用NFS来体会PersistentVolume的使用方法。

9.2.1 NFS PersistentVolume

作为准备工作，我们已经在k8s-master节点上搭建了一个NFS服务器，目录为/nfsdata，如图所示。（详细搭建步骤参见centos7搭建nfs以及挂载完整步骤_猫的树0126的博客-CSDN博客_centos7 nfs）

下面创建一个PV mypv1，配置文件nfs-pv1.yml如下所示。

[root@k8s-master ~]# cat nfs-pv1.yml 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv1
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  nfs:
    path: /nfsdata/pv1
    server: 192.168.1.146
[root@k8s-master ~]#

① capacity指定PV的容量为1GB。

② accessModes指定访问模式为ReadWriteOnce，支持的访问模式有3种：ReadWriteOnce表示PV能以read-write模式mount到单个节点，ReadOnlyMany表示PV能以read-only模式mount到多个节点， ReadWriteMany表示PV能以read-write模式mount到多个节点。

③
persistentVolumeReclaimPolicy指定当PV的回收策略为Recycle，支持的策略有3种：Retain表示需要管理员手工回收；Recycle表示清除PV中的数据，效果相当于执行rm -rf/thevolume/*；Delete表示删除Storage Provider上的对应存储资源，例如AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume等。

④ storageClassName指定PV的class为nfs。相当于为PV设置了一个分类，PVC可以指定class申请相应class的PV。

⑤ 指定PV在NFS服务器上对应的目录。

创建mypv1，如图所示。

STATUS为Available，表示mypv1就绪，可以被PVC申请。

接下来创建PVC mypvc1，配置文件nfs-pvc1.yml如下所示。

[root@k8s-master ~]# cat nfs-pvc1.yml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mypvc1
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: nfs
[root@k8s-master ~]#

PVC就很简单了，只需要指定PV的容量、访问模式和class即可。

创建mypvc1，如图所示。

从kubectl get pvc和kubectl get pv的输出可以看到mypvc1已经Bound到mypv1，申请成功。

接下来就可以在Pod中使用存储了，Pod配置文件pod1.yml如下所示。

[root@k8s-master ~]# cat pod1.yml 
kind: Pod
apiVersion: v1
metadata:
  name: mypod1
spec:
  containers:
    - name: mypod1
      image: busybox
      args:
      - /bin/sh
      - -c
      - sleep 30000
      volumeMounts:
      - mountPath: "/mydata"
        name: mydata
  volumes:
    - name: mydata
      persistentVolumeClaim:
        claimName: mypvc1
[root@k8s-master ~]#

与使用普通Volume的格式类似，在volumes中通过persistentVolumeClaim指定使用mypvc1申请的Volume。

创建mypod1，如图9-14所示。（中间出现过Warning FailedMount 103s kubelet, k8s-node2 MountVolume.SetUp failed for volume "mypv1" : mount failed: exit status 32，在node1和node2安装rpcbind和nfs，同master，后出现mount.nfs: mounting
192.168.1.146:/nfsdata/pv1 failed, reason given by server: No such file or directory，在/nfsdata目录下创建pv1文件夹后解决）

验证PV是否可用，如图所示。

可见，在Pod中创建的文件/mydata/hello确实已经保存到了NFS服务器目录/nfsdata/pv1中。

9.2.2 回收PV

当不需要使用PV时，可用删除PVC回收PV，如图所示。（实测输入删除命令后迟迟无法删除，一直处于Terminating状态，执行kubectl patch pvc mypvc1 -p '{"metadata":{"finalizers":null}}'后可删除）

当PVC mypvc1被删除后，我们发现Kubernetes启动了一个新Pod recycler-for-mypv1，这个Pod的作用就是清除PV mypv1的数据（还需要把mypod1删除，否则不出现）。此时mypv1的状态为Released，表示已经解除了与mypvc1的Bound，正在清除数据，不过此时还不可用。

当数据清除完毕，mypv1的状态重新变为Available（需要删除pv并重新创建），此时可以被新的PVC申请，如图所示。

/nfsdata/pv1中的hello文件已经被删除了（因为为Recycle）。

因为PV的回收策略设置为Recycle，所以数据会被清除，但这可能不是我们想要的结果。如果我们希望保留数据，可以将策略设置为Retain，如下所示。

[root@k8s-master ~]# cat nfs-pv1.yml 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv1
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /nfsdata/pv1
    server: 192.168.1.146
[root@k8s-master ~]#

通过kubectl apply更新PV，如图所示。

回收策略已经变为Retain，通过下面的步骤验证其效果，如图所示。

① 重新创建mypvc1。

② 在mypv1中创建文件hello。

③ mypv1状态变为Released。

④ Kubernetes并没有启动Pod recycler-for-mypv1。

⑤ PV中的数据被完整保留。

虽然mypv1中的数据得到了保留，但其PV状态会一直处于Released，不能被其他PVC申请。为了重新使用存储资源，可以删除并重新创建mypv1。删除操作只是删除了PV对象，存储空间中的数据并不会被删除。

新建的mypv1状态为Available，如图所示，已经可以被PVC 申请。

PV还支持Delete的回收策略，会删除PV在Storage Provider上对应的存储空间。NFS的PV不支持Delete，支持Delete的Provider有AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume等。

9.2.3 PV动态供给

在前面的例子中，我们提前创建了PV，然后通过PVC申请PV并在Pod中使用，这种方式叫作静态供给（Static Provision）。

与之对应的是动态供给（Dynamical Provision），即如果没有满足PVC条件的PV，会动态创建PV。相比静态供给，动态供给有明显的优势：不需要提前创建PV，减少了管理员的工作量，效率高。

动态供给是通过StorageClass实现的，StorageClass定义了如何创建PV，下面给出两个例子。

（1）StorageClass standard，如下所示。

[root@k8s-master ~]# cat storageclass_standard.yml 
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain

[root@k8s-master ~]#

（2）StorageClass slow，如下所示。

[root@k8s-master ~]# cat storageclass_slow.yml 
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  zones: us-east-1d, us-east-1c
  iopsPerGB: "10"
[root@k8s-master ~]#

这两个StorageClass都会动态创建AWS EBS，不同点在于standard创建的是gp2类型的EBS，而slow创建的是io1类型的EBS。不同类型的EBS支持的参数可参考AWS官方文档。

StorageClass支持Delete和Retain两种reclaimPolicy，默认是Delete。

与之前一样，PVC在申请PV时，只需要指定StorageClass、容量以及访问模式即可，如下所示。

[root@k8s-master ~]# cat storageclass_claim.yml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mypvc1
spec:
  accessModes:
    - ReadWriteOnce
  resouces:
    requests:
      storage: 1Gi
  storageClassName: standard
[root@k8s-master ~]#

除了AWS EBS，Kubernetes还支持其他多种动态供给PV的Provisioner，完整列表请参考
https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner。

每天5分钟玩转Kubernetes | PersistentVolume

9.2.1 NFS PersistentVolume

9.2.2 回收PV

9.2.3 PV动态供给

猜你喜欢