一、pc与pvc的概念

在传统的存储卷挂载,比如说nfs,它虽然能够实现我们大多数的生产场景,但是,耦合性比较高;

举例:假设,我们要将集群从“阿里云”迁移到我们私有云服务器上,并改变存储卷挂在的类型,就无法实现,必须使用原有的存储卷类型;比如我们阿里云的存储卷是nfs,我们线下服务器的存储卷是ceph,就无法迁移成功;

那么此时,我们来通过pv与pvc,就可以解决这个耦合性问题了;

二、pvc与pv初体验

我们先按照这个架构图搭建一遍,在来梳理内在的逻辑问题;

1,准别nfs环境

· 所有节点安装nfs工具

harbor安装nfs:是为了作为外部存储卷使用;

k8s231、k8s232、k8s233安装nfs:是为了,自动挂载nfs的时候,使用nfs命令;

yum -y install nfs-utils  

harbor节点编辑nfs配置文件

[root@harbor ~]# vim /etc/exports
/data/kubernetes *(rw,no_root_squash)
[root@harbor ~]# systemctl enable --now nfs
[root@harbor ~]# exportfs
/data/kubernetes
<world>

2,创建3个pv资源

[root@k8s231 pv-pvc]# cat pc.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv01
labels:
k8s: xinjizhiwa
spec:
#声明访问模式
accessModes:
#ReadWriteOnce: 【RWO】 允许单个节点【读写】这个存储卷;
#ReadOnlyMany: 【ROX】 允许多个节点【只读】这个存储卷;
#ReadWriteMany: 【RWX】 允许多个节点【读写】这个存储卷;
#ReadWriteOncePod:【RWOP】允许单个 pod【读写】这个存储卷;1.22版本后新功能;
- ReadOnlyMany
#声明pv的挂载类型
nfs:
path: /data/kubernetes/pv/pv01
server: 10.0.0.230
#声明数据的回收策略
#Retain: 删除PVC时,PV不被删除,状态:已释放,需要手动回收,其他pod否则无法直接使用
#Delete: 删除PVC时,PV和数据都将被删除;
#Recycle:官方已经弃用;(删除PVC时,自动清理对应数据,其他pod可以继续使用)
persistentVolumeReclaimPolicy: Retain
#声明存储卷的容量(给你存多少东西的容量控制)
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv02
labels:
k8s: xinjizhiwa
spec:
accessModes:
- ReadWriteMany
nfs:
path: /data/kubernetes/pv/pv02
server: 10.0.0.230
persistentVolumeReclaimPolicy: Retain
capacity:
storage: 5Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv03
labels:
k8s: xinjizhiwa
spec:
accessModes:
- ReadWriteMany
nfs:
path: /data/kubernetes/pv/pv03
server: 10.0.0.230
persistentVolumeReclaimPolicy: Retain
capacity:
storage: 10Gi
[root@k8s231 pv-pvc]# kubectl apply -f pc.yaml

 查看创建好的pc资源

[root@k8s231 pv-pvc]# kubectl get pv

3,harbor节点创建pv对应的nfs存储路径

[root@harbor ~]# mkdir -pv  /data/kubernetes/pv/pv0{1..3}

4,创建pvc关联pv

pvc链接pv的方式有两种:

第一种:是指定使用哪个pv;

另一种:是不写使用哪个pv,pvc会自动去寻找系统中存在的所有pv,从中匹配一个合适的,进行自动化存储;

[root@k8s231 pv-pvc]# vim pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc01
spec:
# 声明要是用的pv;PVC会根据资源限制自动选择pv存储卷;
# volumeName: pv03 #不写volumeName就会自动根据资源限制自动选择;
# 声明资源的访问模式
accessModes:
- ReadWriteMany
# 声明资源的使用量
resources:
limits:
storage: 4Gi
requests:
storage: 3Gi
[root@k8s231 pv-pvc]# kubectl apply -f pvc.yaml 

查看pvc

因为,我们三个存储卷的pv分别设置了2g、5g、10g的存储容量;

此时我们配置pvc的时候,要求期望是3g,最大值为4g,那么最优的pv选择一定是5g最合适,创建pvc后,我们可以验证查看,自动匹配的pv,就是pv02,存储容量为5g的这个;

[root@k8s231 pv-pvc]# kubectl get pvc

5,创建pod引入pvc

[root@k8s231 pv-pvc]# cat pod.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dm-pv
spec:
replicas: 5
selector:
matchLabels:
k8s: xinjizhiwa
template:
metadata:
labels:
k8s: xinjizhiwa
spec:
volumes:
- name: pvc-vol
#声明pvc存储类型
persistentVolumeClaim:
#引用pvc的名称
claimName: pvc01
containers:
- name: c1
image: nginx:1.20.1-alpine
volumeMounts:
- name: pvc-vol
mountPath: /usr/share/nginx/html/
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: svc-pv-pvc
spec:
type: NodePort
selector:
k8s: xinjizhiwa
ports:
- port: 80
targetPort: 80
nodePort: 8080
[root@k8s231 pv-pvc]# kubectl apply -f pod.yaml

6,编辑index访问文件到harbor存储目录下

[root@harbor ~]# echo xinjizhiwa-hahahahah > /data/kubernetes/pv/pv02/index.html

我们也可以通过查看pv的详细信息,看到存储路径

[root@k8s231 pv-pvc]# kubectl describe pv pv02

7,浏览器访问测试

三、StorageClass动态存储资源

StorageClass动态存储资源:简称sc资源;

动态存储类,它自动创建pv;不再需要手动创建pv;

但是,我们的存储卷系统nfs本身不支持这个sc动态存储,所以,我们需要借助一个插件来实现nfs配合sc资源实现动态自动存储;

整体流程规划汇总;

1,部署nfs环境(存储nfs,和集群的nfs命令)
2,配置nfs动态存储插件;
3,创建StorageClass动态存储资源;
4,创建pvc适配StorageClass动态存储资源
5,创建业务pod引用pvc

1,准备nfs环境

· 所有节点安装nfs

yum -y install nfs-utils

· harbor存储节点配置nfs

[root@harbor ~]# vim /etc/exports
/data/kubernetes *(rw,no_root_squash)
[root@harbor ~]# systemctl enable --now nfs
[root@harbor ~]# exportfs
/data/kubernetes
<world>

· harbor节点创建nfs挂载目录

[root@harbor ~]# mkdir -p /data/kubernetes/storageclass

2,部署配置nfs动态存储插件

注意,nfs的这个插件包中,包含了创建部署服务pod清单,pvc清单和nfs插件清单(deployment.yaml)、storageclass清单(class.yaml);

所以,这个插件包,满足了一切要求了;当然,除了deploymengt.yaml文件外,其他的都不算是插件,都是我们要创建的资源,只是这个插件的构建者,帮助我们把资源清单汇总了;

你也可以自己单独去创建;

· 修改集群api-server,为适配插件中镜像

不设置这一步,nfs的插件镜像无法启动

[root@k8s231 deploy]# vim /etc/kubernetes/manifests/kube-apiserver.yaml 

...........
containers:
- command:
- kube-apiserver
- --service-node-port-range=3000-50000 # 就是加下面这句代码
- --feature-gates=RemoveSelfLink=false .............

插件地址链接:

百度网盘:https://pan.baidu.com/s/106FXTyxJLNWfDStvRqBL1w?pwd=7a91 
提取码:7a91

· 上传解压插件压缩包

[root@k8s231 storageclass]# rz -E
[root@k8s231 storageclass]# tar xf k8s-external-storage.tar.gz
[root@k8s231 storageclass]# ll
drwxr-xr-x 17 root root 4096 Jan 7 07:15 k8s-external-storage
-rw-r--r-- 1 root root 17618638 Jan 7 07:17 k8s-external-storage.tar.gz

· 进入nfs动态配置文件目录

这个插件保重包含很多存储类的动态配置,我们需要进入到nfs动态配置的目录下;

[root@k8s231 storageclass]# cd k8s-external-storage/nfs-client/deploy/
[root@k8s231 deploy]# ll

创建sa用户

[root@k8s231 deploy]# kubectl apply -f rbac.yaml

· 修改插件文件deployment.yaml

[root@k8s231 deploy]# cat 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:
#执行程序的sa用户
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs-client-provisioner
image: quay.io/external_storage/nfs-client-provisioner:latest
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
#对应的StorageClass资源里的provisioner字段值
value: xinjizhiwa-provisioner
- name: NFS_SERVER
value: 10.0.0.230
- name: NFS_PATH
value: /data/kubernetes/storageclass
volumes:
- name: nfs-client-root
nfs:
server: 10.0.0.230
# path: /ifs/kubernetes
path: /data/kubernetes/storageclass

· 创建插件的deployment.yaml文件资源

[root@k8s231 deploy]# kubectl apply -f deployment.yaml

查看是否创建成功

· 修改nfs插件中class.yaml文件

nfs自带的sc资源模板文件,这个文件就是storageclass资源文件;

[root@k8s231 deploy]# vim class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-nfs-storage
#这个值,对应nfs插件的deploymengt.yaml文件中env下的name是PROVISIONER_NAME的value值
provisioner: xinjizhiwa-provisioner
parameters:
#是否删除里面的数据;
#注意:仅对“回收策略是Retain”的值时生效,如果回收策略是delete,则这个参数无效;
#删除数据后,会在存储卷路径创建“archived-*”前缀的目录;
archiveOnDelete: "true"
#在这里设置pv的回收策略(如果不设置,默认是delete)
recalaimPolicy: Retain
[root@k8s231 deploy]# kubectl apply -f class.yaml 

查看sc资源是否成功;

· 创建pvc资源

nfs自带的pvc文件模板

[root@k8s231 deploy]# vim test-claim.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: test-claim
#annotations:
#volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
#指定storageclass资源名称,pvc向哪个storageclass申请pv??
storageClassName: managed-nfs-storage
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Mi
[root@k8s231 deploy]# kubectl apply -f test-claim.yaml

· 验证storageclass是否自动创建了pv?

[root@k8s231 deploy]# kubectl get pv

· 此时查看harbor节点的存储路径

可以看到,创建了pvc之后,nfs挂载目录,就通过sc资源自动创建了一个目录,用于pvc使用;

· 创建pod引用pvc

nfs插件中自带的模板文件

[root@k8s231 deploy]# vim test-pod.yaml
kind: Pod
apiVersion: v1
metadata:
name: test-pod
spec:
containers:
- name: test-pod
#咱们就修改了这个镜像而已;
image: alpine:latest
command:
- "/bin/sh"
args:
- "-c"
- "touch /mnt/SUCCESS && exit 0 || exit 1"
volumeMounts:
- name: nfs-pvc
mountPath: "/mnt"
restartPolicy: "Never"
volumes:
- name: nfs-pvc
persistentVolumeClaim:
claimName: test-claim
[root@k8s231 deploy]# kubectl apply -f test-pod.yaml

· pod运行结束后查看挂载卷路径

证明,动态存储验证成功

1,在创建pvc的时候,sc资源自动创建了pv

2,在创建pvc之后,插卡nfs路径,发现自动创建了pv

3,pod容器运行命令,产生存储数据后,查看nfs存储路径,发现文件生成了;

因此、可以证明,动态存储验证成功;

pod数据持久化-pv与pvc资源及动态存储StorageClass的更多相关文章

  1. 第11章:Pod数据持久化

    参考文档:https://kubernetes.io/docs/concepts/storage/volumes/ Kubernetes中的Volume提供了在容器中挂载外部存储的能力 Pod需要设置 ...

  2. 容器编排系统K8s之PV、PVC、SC资源

    前文我们聊到了k8s中给Pod添加存储卷相关话题,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14180752.html:今天我们来聊一下持久存储卷相关话题 ...

  3. 7.2 k8s 基于PV、PVC搭建zookeeper 3节点集群

    1.PV,PVC介绍 1.1.StorageClass & PV & PVC关系图 Volumes 是最基础的存储抽象,其支持多种类型,包括本地存储.NFS.FC以及众多的云存储,我们 ...

  4. Kubernetes集群PV和PVC详解

    Kubernetes集群高级存储资源PV及PVC 文章目录 Kubernetes集群高级存储资源PV及PVC 1.高级存储PV和PVC概念部分 2.PV和PVC资源的生命周期 3.PV资源介绍与案例配 ...

  5. K8s存储之Volume、PV、PVC、SC

    Volume Volume(存储卷)是Pod中能够被多个容器访问的共享目录.Kubernetes的Volume概念.用途和目的与Docker的Volume比较类似,但两者不能等价.首先,Kuberne ...

  6. pv和pvc状态

    原文地址:https://kubernetes.cn/topics/46 API Server 和 PVController API Server: 这个组件提供对API的支持,响应REST操作,验证 ...

  7. [转]Unity3D游戏开发之数据持久化PlayerPrefs的使用

    转自 http://blog.csdn.net/qinyuanpei/article/details/24195977 首先我们来看两段Unity3D中实现数据读写的简单代码吧: //保存数据 Pla ...

  8. $《第一行代码:Android》读书笔记——第6章 数据持久化

    主要讲述了Android数据持久化的三种方式:文件存储.SharedPreference存储.SQLite数据库存储. (一)文件存储 其实Android中文件存储方式和Java的文件操作类似,就是用 ...

  9. Redis缓存何以一枝独秀?(2) —— 聊聊Redis的数据过期、数据淘汰以及数据持久化的实现机制

    大家好,又见面了. 本文是笔者作为掘金技术社区签约作者的身份输出的缓存专栏系列内容,将会通过系列专题,讲清楚缓存的方方面面.如果感兴趣,欢迎关注以获取后续更新. 上一篇文章中呢,我们简单的介绍了下Re ...

  10. k8s数据持久化,pv和pvc

    k8s中为什么使用存储: k8s中的副本控制器保证了pod的始终存储,却保证不了pod中的数据.只有启动一个新pod的,之前pod中的数据会随着容器的删掉而丢失! pv和pvc的概念: Persist ...

随机推荐

  1. OpenCascade 开源的三维建模几何造型开发平台

    官方文档 https://dev.opencascade.org/doc/overview/html/index.html Open CASCADE(简称OCC)平台是由法国Matra Datavis ...

  2. 最小费用最大流问题的 SSP 算法

    我们已经了解最大流问题,其目标是通过网络中的各条边传输流量,尽可能地从源点流向汇点.通过经典的算法,如 Ford-Fulkerson 增广,我们能够找到一种方式,最大化从源点到汇点的流量. 然而,最大 ...

  3. SignalR 外部调用自定义Hub类的方法,Clients为null

    这是因为外部调用的类的对象和你连接的Hub类的对象,这两个对象 不!一!样! 解决方法 在自定义的Hub类中,注入IHubContext对象,然后在方法中调用IHubContext对象来向前端推送数据 ...

  4. Linux - [-bash: jps: command not found]

    jps是jdk提供的一个查看当前java进程的小工具, 全称是 JavaVirtual Machine Process Status Tool $ jps [options] [hostid] opt ...

  5. devops第一步:CentOS初始化流程

    设置IP vi /etc/sysconfig/network-scripts/ifcfg-ens192 修改下面两个配置 BOOTPROTO=static ONBOOT=yes 添加以下配置 # 改成 ...

  6. PowerShell开发小工具 · 四张照片拼成一张

    小工具的设计与实现------选四张照片拼成一张照片. 很经典的应用情景,市面上有很多类似的小软件,特别是手机应用.为了方便学习巩固PowerShell,今天笔者使用它来实现. [设计思路] 选择四张 ...

  7. JMeter 通过 BeanShell 脚本处理入参和回参

    入参:可以通过该方式动态生成入参参数,如时间参数,随机参数等. 操作:右键 HTTP Request - Add - Pre Processor - BeanShell PreProcessor im ...

  8. docker 超出共享内存限制 RuntimeError: DataLoader

    前言 docker 运行时报错: RuntimeError: DataLoader worker (pid 86) is killed by signal: Bus error. It is poss ...

  9. ESX与ESXi区别

    VMware ESXi 与ESX 产品之比较 VMware vSphere 5.0 以后版本,所有底层虚拟化产品都改为ESXi产品,本文主要比较了ESXi与ESX的各自特点,以便对大家是否要把现有的E ...

  10. Windows下Dll在Unity中使用的一般方式

    Windows下Dll在Unity中使用的一般方式 Unity中虽然已经有广泛的库和插件,但是相较于C++的库生态而言,还是有一定的差距:因此本篇博文记录Windows下将C++函数打包成动态链接库在 ...