k8s的存储卷

存储卷----数据卷

容器内的目录和宿主机的目录进行挂载

容器在系统上的生命周期是短暂的,delete,k8s用控制创建的pod,delete相当于重启,容器的状态也会回复到初始状态

一旦回到初始状态,所有的后天编辑的文件都会消失

容器和节点之间创建一个可以持久化保存容器内文件的存储卷,即使容器被销毁,删除,重启,节点上的存储卷的数据依然存在,后续也可以继续使用,可以继续讲容器内目录和宿主机挂载,保存的数据继续使用

存储的方式

1、emptyDir 容器内部共享存储卷,k8s系统中,是一个pod当中的多个容器共享一个存储卷目录,emptyDir卷可以是pod当中容器在这个存储卷上读取和写入

emptyDir是不能挂载到节点的,随着pod的生命周期结束,emptyDir也会结束,数据也不会保留

,容器内部共享。lnmp

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-xb
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.22
        name: xb
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
#第一个name,存储的名称,可以自定义,mountPath,定义容器内的挂载目录点,和节点或者其他容器的共享目录
      - image: nginx:1.22
        name: xb1
        volumeMounts:
        - name: html
          mountPath: /data/
#引用上一个挂载的名称,表示我将和usr/share/nginx/html这个目录挂载,由data目录和它的目录挂载
        command: ['/bin/sh','-c','while true;do echo $(date) >> /data/index.html;sleep 2;done']
      volumes:
      - name: html
        emptyDir: {}

k8s的存储卷_第1张图片

2、hostPath: 将容器内的挂载,和节点上的目录进行挂载,hostPath可以实现数据的持久化,node节点被销毁,那么数据也会丢失

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
      - name: nginx1
        image: nginx:1.22
        volumeMounts:
        - name: html
          mountPath: /data
        command: ["/bin/bash","-c","while ture; do echo $(date) >> /data/index.html; sleep 2; done"]
      volumes:
      - name: html
        hostPath:
          path: /opt/test
          type: DirectoryOrCreate

k8s的存储卷_第2张图片

3、NFS共享存储

所有pod内的目录都和节点上的nfs共享目录形成数据卷,所有的数据文件都保存在共享目录当中,集中方便管理

在私有仓库上
vim /etc/exports
/data/volumes 20.0.0.0/24(rw,no_root_squash)


在主节点上
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
#第一个name,存储的名称,可以自定义,mountPath,定义容器内的挂载目录点,和节点或者其他容器的共享目录
      - image: nginx:1.22
        name: nginx1
        volumeMounts:
        - name: html
          mountPath: /data
#引用上一个挂载的名称,表示我将和usr/share/nginx/html这个目录挂载,由data目录和它的目录挂载
        command: ["/bin/bash","-c","while ture; do echo $(date) >> /data/index.html; sleep 2; done"]
      volumes:
      - name: html
        nfs:
          path: /data/volumes
          server: 20.0.0.73

pvs和PV

pv:全称Persistent Volume 持久化存储卷,用来描述和定义一个存储卷,pv是由运维人员来定的

pvc:Persistent Volume Claim 持久化存储的请求,pvc实际上是用来描述或者声明我希望使用什么样的pv来进行存储

pvc-pv是一一对应的关系(描述,存储(大小))

pvc--->pv---?

pvc和pv都是虚拟化的概念,是k8s的抽象的虚拟的存储资源

k8s的存储卷_第3张图片

pod内的挂载点声明一个请求pvc请求,pvc会找一个最合适的pv来作为pod的存储卷,pv和共享目录在一一映射,最终由nfs来提供最终的共享存储空间

pvc和pv的请求方式

静态请求

动态请求

pvc和pv之间静态请求,一旦成百个怎么办,所有还有动态pvc

pv是集群当中的存储资源,pvc请求存储资源,也是对存储资源的一个检索(检查索引),选择一个最合适的pv来存储资源

pv和pvc之间是有生命周期管理

1、Provisioning(配置)----- pvc请求request-----检索(找一个合适的pv)---- pvc和pv(binding绑定)---- 使用 ---- pod被删除 ----- pv的relesing(释放)-----recycling(回收)

配置:动态 静态

绑定:就是把pv分配给pvc

使用:就是pod通过pvc使用存储资源

释放:pod解除和Volume的关系,删除pvc

回收:保留pv,让下一个pvc使用

pv的状态

Available:可用,而且没有被任何pvc绑定

Bound:绑定,pv已经绑定了pvc,绑定即使用

released:释放,pvc已经被删除了,但是pv的存储资源还没有被集群回收

Failed:表示pv资源回收失败,而且pv为不可用状态

pv的读写方式

ReadWriteOnce RWO ,配置文件里是全称,存储pv可读可写,但是只能被单个pod挂载

ReadOnlyMany ROX,存储的pv可以以只读的方式被多个pod挂载

ReadWriteMany RWX,存储可以支持读写的方式被多个pod共享

nfs:可以支持三种读写和挂载方式
ISCSI 不支持
hostPath:支持ReadWriteOnce方式

查看设备上所有的Iscsi

[root@master01 opt]# lsscsi 
[1:0:0:0]    cd/dvd  NECVMWar VMware SATA CD01 1.00  /dev/sr0 
[30:0:0:0]   disk    VMware,  VMware Virtual S 1.0   /dev/sda 


iscsiadm -m session -P 3
iscsiadm   查看服务器是否有iscsi设备
-m session	指定操作的会话模块,管理iscsi的会话
-P 3	显示详细信息的级别,级别就是3,显示详细信息
集群回收pv资源的方式

1、Retain 保留,pod和挂载点的数据不会被删除

2、Recycle 回收,pv上的数据被删除,挂载点的数据也被删除

3、Delete:删除,解绑时,自动删除pv上的数据(本地硬盘不能使用,AWS,EBS,GCE)支持动态卷的可以使用,pv不再可用(云平台自己处理)

补充:当pod运行之后,通过pvc请求到了pv,除非pod被销毁,否则无法删除pvc

静态
mkdir v{1,2,3,4,5}
vim/etc/perports
/data/v1 20.0.0.0/24(rw,no_root_squash)
/data/v2 20.0.0.0/24(rw,no_root_squash)
/data/v3 20.0.0.0/24(rw,no_root_squash)
/data/v4 20.0.0.0/24(rw,no_root_squash)
/data/v5 20.0.0.0/24(rw,no_root_squash)

systemctl restart rpcbind
systemctl restart nfs
exportfs -arv

节点上查看
showmount -e 20.0.0.73
Export list for 20.0.0.73:
/data/v5      20.0.0.0/24
/data/v4      20.0.0.0/24
/data/v3      20.0.0.0/24
/data/v2      20.0.0.0/24
/data/v1      20.0.0.0/24
/data/volumes 20.0.0.0/24

主节点
vim pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /data/v1
    server: 20.0.0.73
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /data/v2
    server: 20.0.0.73
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /data/v3
    server: 20.0.0.73
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /data/v4
    server: 20.0.0.73
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 4Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /data/v5
    server: 20.0.0.73
  accessModes: ["ReadWriteMany","ReadWriteOnce","ReadOnlyMany"]
  capacity:
    storage: 5Gi


查看生成的pv
[root@master01 opt]# kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv001   1Gi        RWO,RWX        Retain           Available                                   7s
pv002   2Gi        RWO            Retain           Available                                   7s
pv003   2Gi        RWO,RWX        Retain           Available                                   7s
pv004   4Gi        RWO,RWX        Retain           Available                                   7s
pv005   5Gi        RWO,ROX,RWX    Retain           Available                                   7s

vim pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes: ["ReadWriteMany"]
#pvc期望请求的pv的读写挂载类型是什么
  resources:
    requests:
      storage: 2Gi
#pvc 期望请求pv的存储大小是2G,期望的pv类型:ReadWritemany 大小是2G
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-xb
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.22
        name: xb
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
      volumes:
      - name: html
        persistentVolumeClaim:
          claimName: mypvc

查看
[root@master01 opt]# kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON   AGE
pv001   1Gi        RWO,RWX        Retain           Available                                           144m
pv002   2Gi        RWO            Retain           Available                                           144m
pv003   2Gi        RWO,RWX        Retain           Bound       default/mypvc                           144m
pv004   4Gi        RWO,RWX        Retain           Available                                           144m
pv005   5Gi        RWO,ROX,RWX    Retain           Available                                           144m



pvc --- 请求用哪个pv的存储-----pv和物理存储做映射(挂载)----

删除pvc
[root@master01 opt]# kubectl delete pvc mypvc(会卡)
[root@master01 /]# kubectl delete deployments.apps nginx-xb 
进入kubectl edit pv pv003,删除 claimRef模块

修改pv的资源方式
pv.yaml
......
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  persistentVolumeReclaimPolicy: Recycle
  capacity:
    storage: 4Gi
.....

查看
[root@master01 opt]# kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv001   1Gi        RWO,RWX        Retain           Available                                   151m
pv002   2Gi        RWO            Retain           Available                                   151m
pv003   2Gi        RWO,RWX        Retain           Available                                   151m
pv004   4Gi        RWO,RWX        Recycle          Available                                   151m
pv005   5Gi        RWO,ROX,RWX    Retain           Available                                   151m

你可能感兴趣的:(kubernetes,容器,云原生)