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: {}

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

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的抽象的虚拟的存储资源

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
相关推荐
wenyue112138 分钟前
Revolutionize Your Kubernetes Experience with Easegress: Kubernetes Gateway API
容器·kubernetes·gateway
梅见十柒2 小时前
wsl2中kali linux下的docker使用教程(教程总结)
linux·经验分享·docker·云原生
Python私教3 小时前
ubuntu搭建k8s环境详细教程
linux·ubuntu·kubernetes
运维&陈同学4 小时前
【zookeeper01】消息队列与微服务之zookeeper工作原理
运维·分布式·微服务·zookeeper·云原生·架构·消息队列
O&REO5 小时前
单机部署kubernetes环境下Overleaf-基于MicroK8s的Overleaf应用部署指南
云原生·容器·kubernetes
politeboy5 小时前
k8s启动springboot容器的时候,显示找不到application.yml文件
java·spring boot·kubernetes
运维小文6 小时前
K8S资源限制之LimitRange
云原生·容器·kubernetes·k8s资源限制
登云时刻6 小时前
Kubernetes集群外连接redis集群和使用redis-shake工具迁移数据(二)
redis·容器·kubernetes
wuxingge14 小时前
k8s1.30.0高可用集群部署
云原生·容器·kubernetes
志凌海纳SmartX15 小时前
趋势洞察|AI 能否带动裸金属 K8s 强势崛起?
云原生·容器·kubernetes