【CKA考试笔记】六、存储管理

【CKA考试笔记】六、存储管理
文章目录
实验环境

（vms21）192.168.26.21——master1
（vms22）192.168.26.22——worker1
（vms23）192.168.26.23——worker2
（vms24）192.168.26.24——NFS

概述

如下这样一个pod的yaml：pod1.yaml
```
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: OnFailure
status: {}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
```
我们在将这个pod创建出来
```
kubectl apply -f pod1.yaml
1
```
查看该pod在哪个节点上运行
```
kubectl get pods -o wide
1
```
可以看到它在节点vms23上运行
我们进入pod并创建aaa.txt
```
kubectl exec -it pod1 -- bash
touch aaa.txt
1
2
```
我们来到节点23上，通过文件名查找，能找到该文件
```
find / -name aaa.txt
1
```
此时我们将pod1删除
```
kubectl delete pod pod1
1
```
删除后，再回到vms23查找aaa.txt，就会发现该文件也被删除了
这其实和容器一样，若没有使用数据卷，随着容器的删除，数据就会丢失

因此我们也可以在pod中定义数据卷
定义方法：
在pod的yaml文件中定义
1.在spec下定义pod里的卷
2.在spec.containers下，容器引用该卷

在spec下定义pod里的卷，卷的类型有emptyDir、hostPath、NFS等
```
#没参数时
volumes:
- name: [卷名]
  [卷类型]: {}

#有参数时
volumes:
- name: [卷名]
  [卷类型]: 
    [参数1]: 值1
    [参数2]: 值2

#定义多个卷
volumes:
- name: 卷1
  ...
- name: 卷2
  ...
- name: 卷3
  ...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
```
在容器内引用卷
可以设置readOnly是否只读，若不设置则默认为false，设置为true则容器会以只读的形式挂载，将无法在这个卷内写入数据/文件
```
volumeMounts:
- name: [关联pod里定义的卷名]
  mountPath: [容器内的卷挂载点]
  #readOnly: true
1
2
3
4
```
一、emptyDir 类型卷

emptyDir类型的卷就类似于容器指定数据卷时只指定一个目录（只指定容器内数据卷目录，宿主机中则随机生成一个目录与之映射）的情况

定义emptyDir类型卷：
emptyDir无需参数，因此后面直接是“{}”，即没有指定宿主机数据卷路径，将会在宿主机中随机生成一个目录
```
...
spec:
  volumes:
  - name: v1
    emptyDir: {}
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
    volumeMounts:
    - name: v1
      mountPath: /data
      #readOnly: true
...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
```
创建这个pod，然后我们可以试着进入pod内的容器，并在/data中创建一个文件，然后我们删除这个pod，会发现数据会被一起删除，那么这个emptyDir的意义何在呢？
emptyDir的应用场景：
如下一个节点，里有两个容器，一个主容器，一个辅容器（sidecar）
主容器里主要负责的服务是转码，但是没有提供好的日志分析，日志分析就由sidecar来负责，这些日志不需要永久保留，日志随着pod删除时一起删除就行了，这时emptyDir就很符合这个需要

 二、hostPath

不同于emptyDir，hostPath可以永久保留数据，并且可以指定宿主机的卷目录，创建pod时，会在相应节点上创建该目录

定义hostPath类型卷：
可以添加一个参数path来指定宿主机卷目录
```
...
spec:
  volumes:
  - name: v1
    hostPath:
      path: [宿主机卷目录]
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
    volumeMounts:
    - name: v1
      mountPath: /data
      #readOnly: true
...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
```
使用hostPath也会有一个问题，因为我们目的是想使得数据持久化，使用hostPath，虽然在删除pod后，数据依然能够保留在宿主机（节点）中，但是再次创建这个pod的时候，在不指定的情况下，我们不能保证该pod还会在上次的节点中创建，若不是在上次的节点上，那么之前的数据依然等于是丢失的（各节点间的数据没有同步）

要同步多个节点之间的数据也有一些方法，如：
a.手动同步 rsync
b.搭建一个共享存储，每个节点都挂载上来，即NFS，下面介绍NFS

三、NFS

NFS共享存储会将共享目录自动与各个节点内的一个存储目录挂载起来，当创建pod的时候，就会类似hostPath一样，将pod内的容器与节点的存储目录挂载起来，要使用NFS，所有的worker节点上都必须要安装客户端工具

环境准备：准备一台CentOS7虚拟机（vms24.rhce.cc），ip地址为：192.168.26.24，作为NFS服务端
搭建NFS环境：
所有worker节点及NFS服务端都安装客户端工具nfs-utils
```
yum install nfs-utils -y
1
```
vms24上开启nfs服务端进程，并设为开机自启动
```
systemctl enable nfs-server --now
1
```
vms24上创建一个目录/aa，作为共享存储目录
```
mkdir /aa
1
```
编辑/etc/exports
```
vim /etc/exports

#插入以下内容
#“*”表示允许所有客户端访问，“()”里的内容表示有哪些权限
#no_root_squash 若不写这项，则虽然在节点上时是以root身份访问挂载点，但在nfs服务端，不认为你是root，会压缩权限，加上no_root_squash则在nfs服务端上同样以root身份访问
/aa    *(rw,no_root_squash)
1
2
3
4
5
6
```
保存后，重新加载这个文件
```
exportfs -arv
1
```
在worker节点上测试
```
showmount -e 192.168.26.24
1
```
测试所有worker节点是否能挂载共享目录
```
mount 192.168.26.24:/aa /mnt
1
```
在节点上查看挂载
```
mount | grep 192
1
```
然后卸载
```
umount /mnt
1
```
现在创建一个pod，使用nfs的存储卷类型
数据卷类型为nfs，server定义nfs服务端的地址，path定义nfs服务端的共享目录位置
yaml文件如下：
```
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  volumes:
  - name: v1
    nfs:
      server: 192.168.26.24
      path: /aa
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
    volumeMounts:
    - name: v1
      mountPath: /data
  dnsPolicy: ClusterFirst
  restartPolicy: OnFailure
status: {}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
```
将这个pod创建出来
```
kubectl apply -f xxx.yaml
1
```
进入pod内容器bash，输入“df -hT”
```
kubectl exec -it pod1 -- bash

df -hT
1
2
3
```
可以看到，似乎感觉上是把共享目录/aa与容器内/data挂载起来了
其实共享目录是先与宿主机（worker节点）先挂载起来，然后宿主机与容器挂载起来的
查看该pod在哪个节点上创建
```
kubectl get pods -owide
1
```
我们来到vms23，然后查看挂载信息
```
mount | grep 192
1
```
可以看到挂载到宿主机的目录位置
这样一来，各个worker节点之间都可以同步共享目录里的数据了

NFS缺点：
k8s中有不同的命名空间，不同的用户访问到不同的命名空间，用户1创建一个pod要使用一个挂载点，用户2创建一个pod也想要创建一个挂载点，这时，NFS服务端管理员创建了一个共享目录1给用户1使用，创建了一个共享目录2给用户2使用，那么用户越来越多，共享目录也越来越多，那么让管理员来处理这么多的创建、管理共享目录是不靠谱的

因此，更好的方案是动态卷供应，动态卷供应是基于持久性存储来实现的

 四、持久性存储

在一个k8s环境里，有两个命名空间，命名空间1和命名空间2，用户1登录命名空间1，用户2登录命名空间2
配置了一个NFS共享存储
管理员创建一个pv（persistentVolume）持久性卷，这个pv是全局的，不属于任何命名空间，所有命名空间都能访问这个pv
pv与NFS服务端的共享目录关联
各个用户并不直接访问NFS共享存储，而是在自己的命名空间创建一个pvc（persistentvolumeClaim）持久性卷声明，pvc是基于命名空间的，pvc与pv关联
pvc与pv是一对一关联，一个pv不能同时关联多个pvc，若此时命名空间1的pvc与pv关联了，则其他命名空间的pvc此时就不能与这个pv关联了（Pending），只有在命名空间1的pvc与pv解除关联了，其他命名空间的pvc才可以关联这个pv

master上创建pv：
通过yaml文件创建，可以参考k8s官方模板
yaml文件如下
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv
  #labels:
    #xx: xx
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  #persistentVolumeReclaimPolicy: Recycle
  #storageClassName: slow
  nfs:
    path: /aa
    server: 192.168.26.24
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
```
metadata.labels——定义标签
capacity.storage——定义这个pv提供多大的容量
volumeMode——定义存储系统类型
accessModes——访问类型：
ReadWriteOnce：同时只有一个节点以读写的方式去挂载
ReadOnlyMany：同时多个节点以只读的方式去挂载
ReadWriteMany：同时多个节点以读写的方式去挂载
ReadWriteOncePod：同时只允许一个pod以读写的方式去挂载
persistentVolumeReclaimPolicy——镜像的回收策略：
Recycle：会删除数据，生成一个pod回收数据，删除pvc之后，pv可以复用，pv状态由Released变为Available
Retain：不回收数据，但是删除pvc之后，pv依然不可用，pv状态长期保持为Released
Delete：当使用如阿里云作为云磁盘时，删除云磁盘里的数据
persistentVolumeReclaimPolicy在1.24之后废弃了，默认使用Retain（保留）
nfs——这里定义后的端存储类型，如hostPath等，这里为nfs，所以写nfs，path定义共享目录，server定义服务端地址

在master上创建该pv
```
kubectl apply -f xxx.yaml
1
```
查看该pv
```
kubectl get pv
1
```
查看pv与共享目录的关系信息
```
kubectl describe pv mypv
1
```
master上创建pvc：
通过yaml文件创建，参考模板如下
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 3Gi
  #selector:
    #matchLabels:
      #xx: "xx"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
```
selector.matchLabels——选择器，通过标签匹配，若配置后，该pvc只会关联到含有标签xx=xx的pv上
创建该pvc
```
kubectl apply -f xxx.yaml
1
```
查看该pvc
```
kubectl get pvc
1
```
可以看到该pvc已经关联上了名为mypv的这个pv
那么没有指定时，它是怎么关联上的呢？
有这么几个规则：
（1）pv与pvc定义的accessModes要一致，若不一致则无法匹配
（2）pv里的capacity.storage容量大小要 >= pvc里request.storage的大小，否则无法匹配
（3）若有标签，会有标签控制

如上，mypvc已经和mypv关联上了，此时若把mypvc删除了，此时这个pv的状态会是Released，再次创建mypvc与mypv关联，就会失败（Pending），这是因为回收策略Retain的关系（当删除pvc后，pv里该pvc的数据是不会被删除的，pv与该pvc的关联关系并没有被解除），只有pv状态为Available时，才能让pvc和其匹配
```
kubectl delete pvc mypvc

kubectl get pv
1
2
3
```
```
kubectl apply -f mypvc.yaml

kubecty get pvc
1
2
3
```
此时，只有先删除pv，再次创建pv和pvc，pv状态为Available，才能关联上
```
kubectl delete pvc mypvc
kubectl delete pv mypv
kubectl apply -f mypv.yaml ; kubectl apply -f mypvc.yaml
1
2
3
```
pv与pvc关联后，pod中使用pvc
```
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  volumes:
  - name: v1
    persistentVolumeClaim:
      claimName: mypvc
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
    volumeMounts:
    - name: v1
      mountPath: /data
  dnsPolicy: ClusterFirst
  restartPolicy: OnFailure
status: {}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
```
pod的yaml文件中spec.volumes下，使用persistentVolumeClaim作为卷类型，并用claimName定义使用的pvc名

持续性存储缺点：需要先创建pv、创建pvc，非常麻烦，因此有更好的方案，即动态卷供应

 五、动态卷供应

使用动态卷供应，需要在我们的k8s环境里去创建一个个的分配器（制备器Provisioner）
不同的分配器关联到不同的后端存储中去
创建一个sc（storageClass），这个sc是全局的，不同的命名空间都能访问到
sc中要指定使用的是哪个分配器，即一个sc要是与一个分配器关联在一起的
创建一个pvc，一个pvc要与一个sc关联在一起，当创建pvc的时候，sc会自动帮我们创建一个pv，这个pv与这个pvc关联
综上，sc关联的分配器使用的后端存储是什么，那么pv就与这个后端存储关联在一起
因此管理员只要创建好sc后就不用管pv了，用户创建pvc的时候，sc会自动创建出来一个pv和这个pvc绑定

若我们后端存储使用NFS，但是k8s官方并没有内置NFS的分配器，因此我们需要使用第三方的分配器

nfs-subdir-external-provisioner的下载和安装
下载kubernetes-sigs/nfs-subdir-external-provisioner
地址：https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner
点击tags，下载最新版本，这里下载了nfs-subdir-external-provisioner-nfs-subdir-external-provisioner-4.0.16.tar.gz

在master的root下创建nfs目录，并进入改目录，将下载的nfs-subdir-external-provisioner-nfs-subdir-external-provisioner-4.0.16.tar.gz文件复制进来
```
mkdir nfs
cd nfs
1
2
```
解压该文件
```
tar zxf /root/nfs-subdir-external-provisioner-nfs-subdir-external-provisioner-4.0.16.tar.gz
1
```
ls查看文件，并进入nfs-subdir-external-provisioner-nfs-subdir-external-provisioner-4.0.16
```
cd nfs-subdir-external-provisioner-nfs-subdir-external-provisioner-4.0.16/
1
```
ls查看文件，进入deploy
```
cd deploy
1
```
ls查看文件，可以看到以下这些文件
```
class.yaml  deployment.yaml  objects  rbac.yaml  test-claim.yaml  test-pod.yaml
1
```
其中：
rbae.yaml——这个文件中可以去创建一些权限
deployment.yaml——我们可以通过这个文件查看需要什么镜像，并且通过这个文件来创建分配器
```
grep image deployment.yaml
#输出：
image: k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
1
2
3
```
可以看到需要用到的镜像是：k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner
国内无法访问k8s.gcr.io，所以我这里科学上网下载了
master节点和所有worker节点上都下载这个镜像
```
nerdctl pull k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
1
```
deployment.yaml是用来给我们创建分配器的，我们查看该文件，并需要修改几个地方
```
vim deployment.yaml
1
```
deployment.yaml如下：
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner #分配器名字
            - name: NFS_SERVER
              value: 192.168.26.24
            - name: NFS_PATH
              value: /aa
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.26.24
            path: /aa
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
```
spce.template.spce.containers.env下定义的这几个变量：
PROVISIONER_NAME——分配器名字，下面的value即分配器名字
NFS_SERVER——给分配器指定的后端存储的服务端地址
NFS_PATH——后端存储的目录地址

修改的地方：
a.将NFS_SERVER改为192.168.26.24、将NFS_PATH改为/aa
b.将spce.template.spce.volumes.nfs下的server改为192.168.26.24、将path改为/aa

部署：
确保rabc.yaml、deployment.yaml的命名空间都在default下
```
grep namespace rabc.yaml
grep namespace deployment.yaml
1
2
```
创建权限
```
kubectl apply -f rbac.yaml
#输出：
#serviceaccount/nfs-client-provisioner created
#clusterrole.rbac.authorization.k8s.io/nfs-client-provisioner-runner created
#clusterrolebinding.rbac.authorization.k8s.io/run-nfs-client-provisioner created
#role.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created
#rolebinding.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created
1
2
3
4
5
6
7
```
创建分配器
```
kubectl apply -f deployment.yaml
1
```
查看default命名空间下的pod，检查分配器是否创建成功
```
kubectl get pods -n default
#输出：
NAME                                      READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-74b779d448-j8m67   1/1     Running   0          15s
1
2
3
4
```
创建sc：
回到deploy目录下，找到class.yaml，通过这个文件来创建sc
首先可以编辑class.yaml
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mysc
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # or choose another name, must match deployment's env PROVISIONER_NAME'
parameters:
  archiveOnDelete: "false"
1
2
3
4
5
6
7
```
metadata下的name即sc名称，可以自定义修改
provisioner为分配器名称，必须与deployment.yaml中env配置的PROVISIONER_NAME匹配
然后创建
```
kubectl apply -f class.yaml
1
```
通过kubectl get sc #storageclass简写为sc可以看到sc已经创建出来了
```
NAME   PROVISIONER                                   RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
mysc   k8s-sigs.io/nfs-subdir-external-provisioner   Delete          Immediate           false                  5s
1
2
```
sc和分配器都部署好了，现在就可以尝试来创建pvc了，创建了pvc，sc就会自动帮我们创建一个pv来进行关联
首先，我们需要在pvc的yaml文件中spec下增加storageClassName来指定关联的sc
编辑yaml如下：
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 3Gi
  storageClassName: mysc                       
1
2
3
4
5
6
7
8
9
10
11
12
```
创建pvc
```
kubectl apply -f mypvc.yaml
1
```
创建了pvc后，sc就自动帮我们创建了pv，并绑定
```
kubectl get pvc
#输出：
NAME    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mypvc   Bound    pvc-3e807a34-003f-46c9-8e8c-30b1ec6dfe4b   3Gi        RWO            mysc           7s

kubectl get pv
#输出：
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM           STORAGECLASS   REASON   AGE
pvc-3e807a34-003f-46c9-8e8c-30b1ec6dfe4b   3Gi        RWO            Delete           Bound    default/mypvc   mysc                    15s
1
2
3
4
5
6
7
8
9
```
查看pv挂载的后端存储，可以看到Source中的server、path信息
```
kubectl describe pv pvc-3e807a34-003f-46c9-8e8c-30b1ec6dfe4b

#输出：
Name:            pvc-3e807a34-003f-46c9-8e8c-30b1ec6dfe4b
Labels:          <none>
Annotations:     pv.kubernetes.io/provisioned-by: k8s-sigs.io/nfs-subdir-external-provisioner
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    mysc
Status:          Bound
Claim:           default/mypvc
Reclaim Policy:  Delete
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        3Gi
Node Affinity:   <none>
Message:         
Source:
    Type:      NFS (an NFS mount that lasts the lifetime of a pod)
    Server:    192.168.26.24
    Path:      /aa/default-mypvc-pvc-3e807a34-003f-46c9-8e8c-30b1ec6dfe4b
    ReadOnly:  false
Events:        <none>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
```
sc环境中，用户删除了pvc，pv也会随之删除

定义sc的class.yaml中也有很多的配置项，可以通过kubectl explain sc查看更多的配置项
其中，allowVolumeExpansion这个配置项，设置为true，则可以允许在线修改pvc的requests.storage的大小，也就可以扩展pv的容量大小
编辑class.yaml
```
kubectl edit sc
1
```
添加配置项allowVolumeExpansion为true
```
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"mysc"},"parameters":{"archiveOnDelete":"false"},"provisioner":"k8s-sigs.io/nfs-subdir-external-provisioner"}
  creationTimestamp: "2022-07-05T03:55:01Z"
  name: mysc
  resourceVersion: "850018"
  uid: 7c77e5a3-098c-49d0-8d97-c639a1f13a8d
parameters:
  archiveOnDelete: "false"
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
reclaimPolicy: Delete
volumeBindingMode: Immediate
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
```
相关阅读:
julia系列6：并行计算
 守护绿色屏障：智能高压森林应急消防泵|恒峰智慧科技
 MATLAB创建avi文件
 计算机毕业设计Java校园疫情信息管理系统(源码+系统+mysql数据库+Lw文档）
Process模块怎样在终端进行数据输入？
竞赛题-6233. 温度转换
 RuntimeError: “slow_conv2d_cpu“ not implemented for ‘Half‘
智能家居系统
 呼吁改正《上海市卫生健康信息技术应用创新白皮书》 C# 被认定为A 组件的错误认知
 基于JAVA动漫网站和特效处理系统(Springboot框架+AI人工智能) 开题报告
原文地址：https://blog.csdn.net/weixin_41755556/article/details/125575476

文章目录

实验环境

概述

一、emptyDir 类型卷

二、hostPath

三、NFS

四、持久性存储

五、动态卷供应