前文我们聊到了k8s中给Pod添加存储卷相关话题，回顾请参考：https://www.cnblogs.com/qiuhom-1874/p/14180752.html；今天我们来聊一下持久存储卷相关话题；
volume的基础使用，需要我们用户手动来向不同类型存储接口传递不同的参数，从而实现把外部存储映射到k8s上的一个volume对象，使得pod才能正常的挂载对应的存储卷，对应pod里的容器才能正常使用；这种使用方式的前提是用户必须了解对应的存储系统，了解对应类型的存储接口，以及相关参数；这使得用户在k8s上使用存储卷变得有些复杂；为了简化这一过程，在k8s上使用pv和pvc资源来把对应底层存储接口给隐藏了，用户使用存储卷不再关心底层存储系统接口；不管底层是那种类型的存储，用户只需面对一个pvc接口即可；
PV、PVC和K8s集群以及pod的关系
提示：用户在创建pod时使用存储卷只需要关心对应名称空间的pvc对象；而对应pv是需要集群管理管理员定义；后端存储是专门的存储管理员负责管理；pv是k8s上的一种标准资源，全称叫做PersistentVolume翻译成中文就是持久存储卷；它主要作用是把后端存储中的某个逻辑单元，映射为k8s上的pv资源；pv是集群级别的资源；任意名称空间都可以直接关联某一个pv；关联pv的过程我们叫做绑定pv；而对应名称空间关联某一pv需要使用pvc资源来定义；pvc全称PersistentVolumeClaim的缩写，意思就是持久存储卷申请；在一个名称空间下创建一个pvc就是把对应名称空间同集群上的某一pv做绑定；一旦一个名称空间绑定了一个pv后，对应的pv就会从available状态转变成bond状态，其他名称空间将不能再使用，只有对应pv是available状态才能正常的被其他名称空间关联绑定；简单讲pvc和pv的关系是一一对应的，一个pv只能对应一个pvc；至于同一名称空间下的多个pod是否能够同时使用一个PVC取决pv是否允许多路读写，对应pv是否支持多路读写取决后端存储系统；不同类型的存储系统，对应访问模式也有所不同。访问模式有三种，单路读写(ReadWriteOnce简称RWO)，多路读写(ReadWriteMany简称RWX)，多路只读(ReadOnlyMany简称ROX)；
示例：pv资源创建
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
[root@master01 ~]
# cat pv-v1-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv-v1
labels:
storsystem: nfs-v1
rel: stable
spec:
capacity:
storage: 1Gi
volumeMode: Filesystem
accessModes: [
"ReadWriteOnce"
,
"ReadWriteMany"
,
"ReadOnlyMany"
]
persistentVolumeReclaimPolicy: Retain
mountOptions:
- hard
- nfsvers=4.1
nfs:
path:
/data/v1
server: 192.168.0.99
[root@master01 ~]
#
|
提示：pv是k8s的标准资源，其群组版本为v1,类型为PersistentVolume；spec.capacity.storage字段用来描述pv的存储容量；volumeMode用来描述对应存储系统提供的存储卷类型接口，一般存储卷类型接口有两种，分别是文件系统接口和块设备接口；accessModes用来描述pv的访问模式；presistentVolumeReclaimPolicy字段用来描述存储卷回收策略，持久卷回收策略有3中，一种是Delete，表示当pvc删除以后，对应pv也随之删除；第二种是Recycle,表示当pvc删除以后，对应pv的数据也随之被删除；第三种是Retain表示当pvc被删除以后，pv原封动，即pv也在，对应数据也在；mountOptions字段用来指定挂载选项；nfs表示后端存储为nfs，对于不同类型的存储，对应的要传递的参数各不相同，对于nfs这种类型的存储，我们只需要指定其nfs服务器地址以及对应共享出来的文件路径；以上配置就表示把nfs上的/data/v1目录映射到k8s上的pv，对应pv的名称为nfs-pv-v1；这里需要注意一点，在创建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
|
[root@master01 ~]
# kubectl apply -f pv-v1-demo.yaml
persistentvolume
/nfs-pv-v1
created
[root@master01 ~]
# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv-v1 1Gi RWO,ROX,RWX Retain Available 4s
[root@master01 ~]
# kubectl describe pv nfs-pv-v1
Name: nfs-pv-v1
Labels: rel=stable
storsystem=nfs-v1
Annotations: <none>
Finalizers: [kubernetes.io
/pv-protection
]
StorageClass:
Status: Available
Claim:
Reclaim Policy: Retain
Access Modes: RWO,ROX,RWX
VolumeMode: Filesystem
Capacity: 1Gi
Node Affinity: <none>
Message:
Source:
Type: NFS (an NFS
mount
that lasts the lifetime of a pod)
Server: 192.168.0.99
Path:
/data/v1
ReadOnly:
false
Events: <none>
[root@master01 ~]
#
|
提示：在pv的详细信息中能够看到，当前pv的状态为available，pv对应后端的存储是nfs，对应存储的ip地址为192.168.0.99，当前pv对应后端存储的逻辑单元就是/data/v1；
示例：创建pvc
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
[root@master01 ~]
# cat pvc-v1-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-nfs-pv-v1
namespace: default
labels:
storsystem: nfs-v1
spec:
accessModes:
- ReadWriteMany
volumeMode: Filesystem
resources:
requests:
storage: 500Mi
selector:
matchLabels:
storsystem: nfs-v1
rel: stable
[root@master01 ~]
#
|
提示：pvc也是k8s上的标准资源，对应的群组版本为v1,类型为PersistentVolumeClaim；其中spec.accessModes字段是用来指定其pvc的访问模式，一般这个模式是被pv的accessModes包含，也就说pvc的访问模式必须是pv的子集，即等于小于pv的访问模式；resources用来描述对应pvc的存储空间限制，requests用来描述对应pvc最小容量限制，limits用来描述最大容量限制；selector用来定义标签选择器，主要作用过滤符合对应标签的pv；如果不定义标签选择器，它会在所有available状态的pv中，通过其容量大小限制以及访问模式去匹配一个最佳的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
|
[root@master01 ~]
# kubectl apply -f pvc-v1-demo.yaml
persistentvolumeclaim
/pvc-nfs-pv-v1
created
[root@master01 ~]
# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs-pv-v1 Bound nfs-pv-v1 1Gi RWO,ROX,RWX 8s
[root@master01 ~]
# kubectl describe pvc pvc-nfs-pv-v1
Name: pvc-nfs-pv-v1
Namespace: default
StorageClass:
Status: Bound
Volume: nfs-pv-v1
Labels: storsystem=nfs-v1
Annotations: pv.kubernetes.io
/bind-completed
:
yes
pv.kubernetes.io
/bound-by-controller
:
yes
Finalizers: [kubernetes.io
/pvc-protection
]
Capacity: 1Gi
Access Modes: RWO,ROX,RWX
VolumeMode: Filesystem
Used By: <none>
Events: <none>
[root@master01 ~]
# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv-v1 1Gi RWO,ROX,RWX Retain Bound default
/pvc-nfs-pv-v1
19m
[root@master01 ~]
#
|
提示：这里显示pvc的大小是pvc最大容量显示，默认不限制最大容量就是其pv的最大容量；从上面的显示可以看到对应pv被pvc绑定以后，其状态就变成了bound；
示例：创建pod关联pvc，并在其pod容器里挂载pvc
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
[root@master01 ~]
# cat redis-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: redis-demo
labels:
app: redis
spec:
containers:
- name: redis
image: redis:alpine
volumeMounts:
- mountPath:
/data
name: redis-data
volumes:
- name: redis-data
persistentVolumeClaim:
claimName: pvc-nfs-pv-v1
[root@master01 ~]
#
|
提示：在pod里关联pvc，只需要指定后端存储类型为persistentVolumeClaim，然后指定对应的pvc名称；
应用资源清单
|
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
|
[root@master01 ~]
# kubectl apply -f redis-demo.yaml
pod
/redis-demo
created
[root@master01 ~]
# kubectl get pod
NAME READY STATUS RESTARTS AGE
redis-demo 0
/1
ContainerCreating 0 7s
[root@master01 ~]
# kubectl get pod
NAME READY STATUS RESTARTS AGE
redis-demo 1
/1
Running 0 27s
[root@master01 ~]
# kubectl describe pod redis-demo
Name: redis-demo
Namespace: default
Priority: 0
Node: node03.k8s.org
/192
.168.0.46
Start Time: Fri, 25 Dec 2020 21:55:41 +0800
Labels: app=redis
Annotations: <none>
Status: Running
IP: 10.244.3.105
IPs:
IP: 10.244.3.105
Containers:
redis:
Container ID: docker:
//8e8965f52fd0144f8d6ce68185209114163a42f8437d7d845d431614f3d6dd05
Image: redis:alpine
Image ID: docker-pullable:
//redis
@sha256:68d4030e07912c418332ba6fdab4ac69f0293d9b1daaed4f1f77bdeb0a5eb048
Port: <none>
Host Port: <none>
State: Running
Started: Fri, 25 Dec 2020 21:55:48 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/data
from redis-data (rw)
/var/run/secrets/kubernetes
.io
/serviceaccount
from default-token-xvd4c (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
redis-data:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim
in
the same namespace)
ClaimName: pvc-nfs-pv-v1
ReadOnly:
false
default-token-xvd4c:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-xvd4c
Optional:
false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io
/not-ready
:NoExecute
op
=Exists
for
300s
node.kubernetes.io
/unreachable
:NoExecute
op
=Exists
for
300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 37s default-scheduler Successfully assigned default
/redis-demo
to node03.k8s.org
Normal Pulling 36s kubelet Pulling image
"redis:alpine"
Normal Pulled 30s kubelet Successfully pulled image
"redis:alpine"
in
5.284107704s
Normal Created 30s kubelet Created container redis
Normal Started 30s kubelet Started container redis
[root@master01 ~]
#
|
提示：可以看到对应pod已经正常运行起来；从详细信息中可以看到对应pod使用的volumes类型为PersistentVolumeClaim，对应名称为pvc-nfs-pv-v1；对应容器以读写方式挂载了对应存储卷；
测试：在redis-demo上产生数据，看看是否能够正常保存到nfs服务器上？
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
[root@master01 ~]
# kubectl get pod
NAME READY STATUS RESTARTS AGE
redis-demo 1
/1
Running 0 5m28s
[root@master01 ~]
# kubectl exec -it redis-demo -- /bin/sh
/data
# redis-cli
127.0.0.1:6379>
set
mykey
"this is test key "
OK
127.0.0.1:6379> get mykey
"this is test key "
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379>
exit
/data
# ls
dump.rdb
/data
#
|
在nfs服务器上查看对应目录下是否有dump.rdb文件产生？
|
1
2
3
4
|
[root@docker_registry ~]
# ll /data/v1
total 4
-rw-r--r-- 1 polkitd qiuhom 122 Dec 25 22:02 dump.rdb
[root@docker_registry ~]
#
|
提示：可以看到，redis上产生的快照文件在nfs服务器上有对应的文件存在；
测试：删除pod，看看对应文件是否还在？
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
[root@master01 ~]
# kubectl delete -f redis-demo.yaml
pod
"redis-demo"
deleted
[root@master01 ~]
# kubectl get pods
No resources found
in
default namespace.
[root@master01 ~]
# ssh 192.168.0.99
The authenticity of host
'192.168.0.99 (192.168.0.99)'
can't be established.
ECDSA key fingerprint is SHA256:hQoossQnTJMXB0+DxJdTt6DMHuPFLDd5084tHyJ7920.
ECDSA key fingerprint is MD5:ef:61:b6:ee:76:46:9d:0e:38:b6:b5:
dd
:11:66:23:26.
Are you sure you want to
continue
connecting (
yes
/no
)?
yes
Warning: Permanently added
'192.168.0.99'
(ECDSA) to the list of known hosts.
root@192.168.0.99's password:
Last login: Fri Dec 25 20:13:05 2020 from 192.168.0.232
[root@docker_registry ~]
# ll /data/v1
total 4
-rw-r--r-- 1 polkitd qiuhom 122 Dec 25 22:05 dump.rdb
[root@docker_registry ~]
# exit
logout
Connection to 192.168.0.99 closed.
[root@master01 ~]
#
|
提示：可以看到删除了pod对应快照文件在nfs服务器还是存在；
绑定节点，重新新建pod，看看对应是否能够自动应用快照中的数据？
|
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
|
[root@master01 ~]
# cat redis-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: redis-demo
labels:
app: redis
spec:
nodeName: node01.k8s.org
containers:
- name: redis
image: redis:alpine
volumeMounts:
- mountPath:
/data
name: redis-data
volumes:
- name: redis-data
persistentVolumeClaim:
claimName: pvc-nfs-pv-v1
[root@master01 ~]
# kubectl apply -f redis-demo.yaml
pod
/redis-demo
created
[root@master01 ~]
# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
redis-demo 0
/1
ContainerCreating 0 8s <none> node01.k8s.org <none> <none>
[root@master01 ~]
# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
redis-demo 1
/1
Running 0 21s 10.244.1.88 node01.k8s.org <none> <none>
[root@master01 ~]
#
|
提示：可以看到新建的pod被调度到node01上了；
进入对应pod，看看是否应用了其快照文件中的数据？对应key是否能够被应用到内存？
|
1
2
3
4
5
6
7
8
9
10
11
12
|
[root@master01 ~]
# kubectl get pods
NAME READY STATUS RESTARTS AGE
redis-demo 1
/1
Running 0 2m39s
[root@master01 ~]
# kubectl exec -it redis-demo -- /bin/sh
/data
# redis-cli
127.0.0.1:6379> get mykey
"this is test key "
127.0.0.1:6379>
exit
/data
# ls
dump.rdb
/data
# exit
[root@master01 ~]
#
|
提示：可以看到新建的pod能够正常读取到nfs上的快照文件并应用到内存中；
删除pvc，看看对应pv是否被删除？
提示：可以看到在没有删除pod的情况下，对应删除操作被阻塞了；
查看pvc状态
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
[root@master01 ~]
# kubectl delete pvc pvc-nfs-pv-v1
persistentvolumeclaim
"pvc-nfs-pv-v1"
deleted
^C
[root@master01 ~]
# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs-pv-v1 Terminating nfs-pv-v1 1Gi RWO,ROX,RWX 34m
[root@master01 ~]
# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs-pv-v1 Terminating nfs-pv-v1 1Gi RWO,ROX,RWX 34m
[root@master01 ~]
# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs-pv-v1 Terminating nfs-pv-v1 1Gi RWO,ROX,RWX 34m
[root@master01 ~]
# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv-v1 1Gi RWO,ROX,RWX Retain Bound default
/pvc-nfs-pv-v1
52m
[root@master01 ~]
#
|
提示：可以看到现在pvc的状态变成了terminating，但对应pvc还在并没有被删除；对应pv还处于绑定状态；
删除pod，看看对应pvc是否会被删除呢？
|
1
2
3
4
5
6
7
8
9
10
11
|
[root@master01 ~]
# kubectl get pod
NAME READY STATUS RESTARTS AGE
redis-demo 1
/1
Running 0 14m
[root@master01 ~]
# kubectl delete pod redis-demo
pod
"redis-demo"
deleted
[root@master01 ~]
# kubectl get pvc
No resources found
in
default namespace.
[root@master01 ~]
# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv-v1 1Gi RWO,ROX,RWX Retain Released default
/pvc-nfs-pv-v1
54m
[root@master01 ~]
#
|
提示：可以看到删除对应pod以后，pvc就立即删除了；对应pvc被删除以后，对应pv的状态就从bound状态转变为Released状态，表示等待回收；我们在资源清单中使用的是Retain回收策略，pv和pvc都是我们人工手动回收；
删除pv，看看对应数据是否会被删除？
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
[root@master01 ~]
# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv-v1 1Gi RWO,ROX,RWX Retain Released default
/pvc-nfs-pv-v1
57m
[root@master01 ~]
# kubectl delete pv nfs-pv-v1
persistentvolume
"nfs-pv-v1"
deleted
[root@master01 ~]
# kubectl get pv
No resources found
[root@master01 ~]
# ssh 192.168.0.99
root@192.168.0.99's password:
Last login: Fri Dec 25 22:05:53 2020 from 192.168.0.41
[root@docker_registry ~]
# ll /data/v1
total 4
-rw-r--r-- 1 polkitd qiuhom 122 Dec 25 22:24 dump.rdb
[root@docker_registry ~]
# exit
logout
Connection to 192.168.0.99 closed.
[root@master01 ~]
#
|
提示：可以看到删除了pv，对应快照文件并没有清除；
以上就是pv和pvc资源的用法，下面我们再来说一下sc资源
SC是StorageClass的缩写，表示存储类；这种资源主要用来对pv资源的自动供给提供接口；所谓自动供给是指用户无需手动创建pv，而是在创建pvc时对应pv会由persistentVolume-controller自动创建并完成pv和pvc的绑定；使用sc资源的前提是对应后端存储必须支持restfull类型接口的管理接口，并且pvc必须指定对应存储类名称来引用SC；简单讲SC资源就是用来为后端存储提供自动创建pv并关联对应pvc的接口；如下图
提示：使用sc动态创建pv，对应pvc必须也是属于对应的sc；上图主要描述了用户在创建pvc时，引用对应的sc以后，对应sc会调用底层存储系统的管理接口，创建对应的pv并关联至对应pvc；
示例：创建sc资源
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
apiVersion: storage.k8s.io
/v1
kind: StorageClass
metadata:
name: slow
provisioner: kubernetes.io
/glusterfs
parameters:
resturl:
"http://127.0.0.1:8081"
clusterid:
"630372ccdc720a92c681fb928f27b53f"
restauthenabled:
"true"
restuser:
"admin"
secretNamespace:
"default"
secretName:
"heketi-secret"
gidMin:
"40000"
gidMax:
"50000"
volumetype:
"replicate:3"
|
提示：上述是官方文档中的一个示例，在创建sc资源时，对应群组是storage.k8s.io/v1，类型为StorageClass；provisioner字段用于描述对应供给接口名称；parameters用来定义向对应存储管理接口要传递的参数；
在pvc资源中引用SC资源对象
|
1
2
3
4
5
6
7
8
9
|
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: foo-pvc
namespace: foo
spec:
storageClassName:
"slow"
volumeName: foo-pv
...
|
提示：在创建pvc时用storageClassName字段来指定对应的SC名称即可；