在Docker中我们知道，要想实现数据的持久化（所谓Docker的数据持久化即数据不随着Container的结束而结束），需要将数据从宿主机挂载到容器中，常用的手段就是Volume数据卷。在K8S中，也提供了存储模型Volume，支持我们将应用中的数据持久化存储到容器中。
（1）学习Volume，以及Kubernetes如何通过Volume为集群中的容器提供存储；
（2）实践几种常用的Volume类型并理解它们各自的应用场景；
（3）学习Kubernetes如何通过 PersistentVolume和PersistentVolumeClaim分离集群管理员与集群用户的职责，并实践Volume的静态供给和动态供给。
1.1 使用K8S Volume
（1）emptyDir
作为K8S最基础的Volume类型，emptyDir提供了最基础的持久化方案，但是这个方案不怎么好。因为，emptyDir对于Pod来说并非持久的（它对于容器来说是持久化的），因为当Pod从节点删除时，Volume的内容也会被删除。但如果只是容器被销毁而Pod还在，则Volume不会受影响。
换句话说：emptyDirVolume的生命周期与Pod一致。鉴于此特性，不建议在实际中使用此类型Volume。
vi volume-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: producer-consumer
spec:
containers:
- image: busybox
name: producer
volumeMounts:
- mountPath: /producer_dir
name: shared-volume
args:
- "/bin/sh"
- "-c"
- "echo 'hello world' > /producer_dir/hello; sleep 30000"
- image: busybox
name: consumer
volumeMounts:
- mountPath: /consumer_dir
name: shared-volume
args:
- "/bin/sh"
- "-c"
- "cat /consumer_dir/hello; sleep 30000"
volumes:
- name: shared-volume
emptyDir: {}
这里我们模拟了⼀个producer-consumer场景。Pod有两个容器producer和consumer，它们共享⼀个Volume。producer负责往Volume中写数据，consumer则是从Volume读取数据。
①文件最底部volumes定义了⼀个emptyDir类型的Volume shared-volume。
②producer容器将shared-volumemount到/producer_dir目录。
③producer通过echo将数据写到文件hello里。
④consumer容器将shared-volumemount到/consumer_dir目录。
⑤consumer通过cat从文件hello读数据。
[root@k8s-master ~]# vi volume-demo.yaml
[root@k8s-master ~]# kubectl apply -f volume-demo.yaml
pod/producer-consumer created
[root@k8s-master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
producer-consumer 0/2 ContainerCreating 0 5s
[root@k8s-master ~]# kubectl logs producer-consumer consumer
hello world
kubectl logs显示容器consumer成功读到了producer写入的数据，验证了两个容器共享emptyDir Volume。
emptyDir是Host上创建的临时目录，其优点是能够方便地为Pod中的容器提供共享存储，不需要额外的配置。
1.2 hostPath
相对于emptyDir，hotPath则克服了其生命周期的弱点，如果Pod被销毁，hostPath对应的目录还是会被保留。不过，如果一旦Host崩溃，hostPath也就无法访问了。因为，hostPath是将DockerHost文件系统中已经存在的目录mount给Pod的容器，所以会依赖于Host。
大部分应用都不会使用hostPath Volume，因为这实际上增加了Pod与节点的耦合，限制了Pod的使用。不过那些需要访问Kubernetes或Docker内部数据（配置文件和⼆进制库）的应用则需要使用hostPath。
1.3 外部Storage Provider
如果Kubernetes部署在诸如AWS、GCE、Azure等公有云上，可以直接使用云硬盘作为Volume。下面给出⼀个AWSElasticBlockStore的例子。
vi volume-demo1.yaml
apiVersion: v1
kind: Pod
metadata:
name: using-ebs
spec:
containers:
- image: busybox
name: using-ebs
volumeMounts:
- mountPath: /test-ebs
name: ebs-volume
volumes:
- name: ebs-volume
awsElasticBlockStore:
volumeID: <volume-id> # Replace <volume-id> with the actual volume ID
fsType: ext4
Kubernetes Volume也可以使用主流的分布式存储，比如Ceph、GlusterFS等。
1.4 PersistentVolume &PersistentVolumeClaim
PV是外部存储系统中的一块存储空间，由管理员创建和维护。与Volume一样，PV具有持久性，生命周期独立于Pod。
PVC则是对PV的申请（Claim），PVC通常由普通用户创建和维护。当需要为Pod分配存储资源的时候，用户就可以创建一个PVC，指明存储资源的容量大小和访问方式（比如ReadOnly）等信息，K8S会查找并提供满足条件的PV。
与K8S Volume一样，K8S PersistentVolume也支持多种类型的存储，比如NFS、AWS EBS、Ceph等等。
1.5 NFS PV的使用
作为准备工作，我们已经在k8s-master节点上搭建了⼀个NFS服务器，目录为/nfsdata。
[root@k8s-master nfs]# showmount -e
Export list for k8s-master:
/nfsdata *
创建目录 pv1 后面使用
mkdir /nfsdata/pv1
chmod o+w /nfsdata/pv1
下面创建⼀个PV mypv1，配置文件nfs-pv1.yml如下所示
vi 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.200.128
① 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表示删除StorageProvider上的对应存储资源，例如AWSEBS、GCEPD、AzureDisk、OpenStackCinderVolume等。
④ storageClassName指定PV的class为nfs。相当于为PV设置了⼀个
分类，PVC可以指定class申请相应class的PV。
⑤ 指定PV在NFS服务器上对应的目录。
创建mypv1，如下所示：
[root@k8s-master ~]# kubectl apply -f nfs-pv1.yml
persistentvolume/mypv1 created
[root@k8s-master ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mypv1 1Gi RWO Recycle Available nfs 11s
STATUS为Available，表示mypv1就绪，可以被PVC申请。
接下来创建PVC mypvc1，配置文件nfs-pvc1.yml如下所示。
vi nfs-pvc1.yml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: mypvc1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: nfs
PVC就很简单了，只需要指定PV的容量、访问模式和class即可。
创建mypvc1，如下所示：
[root@k8s-master ~]# kubectl apply -f nfs-pvc1.yml
persistentvolumeclaim/mypvc1 created
[root@k8s-master ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mypvc1 Bound mypv1 1Gi RWO nfs 7s
[root@k8s-master ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mypv1 1Gi RWO Recycle Bound default/mypvc1 nfs 2m59s
pv-volume-mysql 8Gi RWO Retain Released default/my-mysql 25d
从kubectl get pvc和kubectl get pv的输出可以看到mypvc1已经Bound到mypv1，申请成功。
接下来就可以在Pod中使用存储了，Pod配置文件nfs-pod1.yml如下所示：
vi nfs-pod1.yml
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
创建mypod1，如下所示。
[root@k8s-master ~]# kubectl describe pod mypod1
Name: mypod1
Namespace: default
Priority: 0
Node: k8s-node2/192.168.200.130
Start Time: Thu, 29 Feb 2024 13:31:14 +0800
Labels: <none>
Annotations: Status: Running
验证PV是否可用
[root@k8s-master ~]# kubectl exec mypod1 -- touch /mydata/hello
[root@k8s-master ~]# ls /nfsdata/pv1/
hello test.txt
可见，在Pod中创建的文件/mydata/hello确实已经保存到了NFS服务器目录/nfsdata/pv1中。
1.6 回收PV
当不需要使用PV时，可用删除PVC回收PV
[root@k8s-master ~]# kubectl delete pvc mypvc1
[root@k8s-master ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mypv1 1Gi RWO Recycle Released default/mypvc1
此时mypv1的状态为Released，表示已经解除了与mypvc1的Bound，正在清除数据，不过此时还不可用。
当数据清除完毕，mypv1的状态重新变为Available，此时可以被新的PVC申请。
[root@k8s-master ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mypv1 1Gi RWO Recycle Available default/mypvc1
因为PV的回收策略设置为Recycle，所以数据会被清除，但这可能不是我们想要的结果。如果我们希望保留数据，可以将策略设置为Retain。
vi 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.200.128
通过kubectl apply更新PV，回收策略已经变为Retain。
1.7 PV动态供给
在前面的例子中，我们提前创建了PV，然后通过PVC申请PV并在Pod中使用，这种方式叫作静态供给（Static Provision）。
与之对应的是动态供给（DynamicalProvision），即如果没有满足PVC条件的PV，会动态创建PV。相比静态供给，动态供给有明显的优势：不需要提前创建PV，减少了管理员的工作量，效率高。
动态供给是通过StorageClass实现的，StorageClass定义了如何创建PV，下面给出两个例子。
（1）StorageClass standard
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
reclaimPolicy: Retain
（2）StorageClass slow
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"
这两个StorageClass都会动态创建AWSEBS，不同点在于standard创建的是gp2类型的EBS，而slow创建的是io1类型的EBS。
不同类型的EBS支持的参数可参考AWS官方文档。
StorageClass支持Delete和Retain两种reclaimPolicy，默认是 Delete。与之前⼀样，PVC在申请PV时，只需要指定StorageClass、容量以及访问模式即可，如下所示。
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: mypvc1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: standard
除了AWSEBS，Kubernetes还支持其他多种动态供给PV的Provisioner，完整列表请参考https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
