Kubernetes 1.19.0——存储管理

当把pod删除了，那么pod里所有的数据也就没有了

所以这个问题怎么解决呢？配置卷

emptyDir

emptyDir: 本地卷，在物理机里随机生成一个目录

如果pod被删除，则物理机里对应的目录也会被删除，不是永久性存储

先创建一个yaml模板然后修改

定义卷的格式：

volumes:

-  name:

  emptyDir: {}

根据docker inspect ID查找到/xx,映射到物理机的此目录

进入容器的/xx目录下创建一个aa.txt文件

Vms63上的挂载目录下同样的多出一个相同的文件

删除对应pod，目录也会被删除无法访问

hostPath

hostPath:类似于docker run -v /data:/xx   

配置hostPath的文件映射至/data目录

成功映射到data目录

当删除pod后，检查/data目录数据仍然还在，这里不作演示

NFS

NFS:网络卷

如果pod出问题导致重启而从原本的节点运行至其他节点，这个时候新节点没有原本节点的目录导致数据不一致或者其他问题，怎么办？使用NFS网络存储

另外准备一台机器vms50作为存储服务器并安装相关软件包并设置rpcbind和nfs-server开机自启

只允许192.168.135.0/24这个网段来访问我的存储且用root的权限不作任何压缩

本次实验用*表示允许任何客户端访问，注意*与括号之间没有空格

通过exportsfs -arv让其生效

注：虽然是在pod上挂载的，但是必须在worker上 安装客户端，不然没有showmount命令在所有节点安装yum -y install nfs-u*

测试成功挂载

修改配置，192.168.135.50这个server下的/vdisk的目录挂载到了/xx

进入容器后查看，挂载成功

创建一个aa.txt，共享存储上也成功同步

在/vdisk创建文件，则容器里也会同步出现相同文件，这里不作演示

到此nfs搭建完成，就算pod移至其他节点也不会影响数据一致性

持久性存储

PV是全局的，所有命名空间是可见的

ReadWriteOnce：同时只有一个去读写

ReadOnlyMany：同时有多个去读，不能写

ReadWriteMany：同时有多个去读写

apiVersion: v1

kind: PersistentVolume

metadata:

name: pv01

spec:

capacity:

storage: 5Gi

volumeMode: Filesystem

accessModes:

- ReadWriteOnce

persistentVolumeReclaimPolicy: Recycle

nfs:

path:/aa

server: 192.168.135.50

成功创建一个名为pv01的pv，状态为available时pvc才能和pv进行关联

所有命名空间都可查看到，全局可见

通过kubectl describe pv pv01查看详细信息

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: mypvc1

spec:

  accessModes:

    - ReadWriteOnce

  volumeMode: Filesystem

  resources:

    requests:

      storage: 5Gi

成功创建mypvc1并成功关联pv01

accessModes必须一样，且pvc大小要小于等于pv大小，两者才能成功关联

注：一个pv一次只能和一个pvc进行关联

以上的pv和pvc的storageClassName的值不一样，导致一直pending关联不上

需要改成一样的值才能关联，这里为节约篇幅不作演示

pv回收策略

• Recycle --会删除数据

• 会生成一个pod回收数据

• 删除pvc之后，pv可复用

• pv状态由Released变为Available

• Retain--不回收数据

• 但是删除pvc之后，pv依然不可用

• pv状态长期保持为 Released

修改回收策略为Retain后再删除pod就不会影响数据的丢失

官网原文：

A user creates, or has already created in the case of dynamic provisioning, a PersistentVolumeClaim with a specific amount of storage requested and with certain access modes.

A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together.

If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested.

Once bound, PersistentVolumeClaim binds are exclusive, regardless of how they were bound. A PVC to PV binding is a one-to-one mapping.