一万年来谁著史,三千里外欲封侯。这篇文章主要讲述kubernetes 使用 PV 和 PVC 管理数据存储相关的知识,希望能为你提供帮助。
文章链接
容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet
会重启它,但是容器中的文件将丢失——容器以干净的状态(镜像最初的状态)重新启动。其次,在 Pod
中同时运行多个容器时,这些容器之间通常需要共享文件。所以我会用 NFS
为例,创建 PV
、PVC
.
PV 属于集群中的资源。PVC 是对这些资源的请求,也作为对资源的请求的检查。 PV 和 PVC 之间的相互作用遵循这样的生命周期.
PersistentVolume(PV)PersistentVolume
(PV)是由管理员设置的存储,它是群集的一部分。就像节点是集群中的资源一样,PV 也是集群中的资源。 PV 是 Volume 之类的卷插件,但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节,即 NFS、iSCSI 或特定于云供应商的存储系统。
PV 有两种方式来配置:静态和动态。
- 静态
集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中,可用于消费。 - 动态
根据 StorageClasses,当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时,集群可能会尝试动态地为 PVC 创建卷。 安装并配置 nfs rpcbind
yum install -y nfs-utils rpcbind mkdir -p /home/bsh/nfs vim /etc/exports /home/bsh/nfs *(rw,sync,no_root_squash)
配置详解:
---|---
ro|只读访问
rw|读写访问
sync|所有数据在请求时写入共享
async|NFS在写入数据前可以相应请求
secure|NFS通过1024以下的安全TCP/IP端口发送
insecure|NFS通过1024以上的端口发送
wdelay|如果多个用户要写入NFS目录,则归组写入(默认)
no_wdelay|如果多个用户要写入NFS目录,则立即写入,当使用async时,无需此设置。
Hide|在NFS共享目录中不共享其子目录
no_hide|共享NFS目录的子目录
subtree_check|如果共享/usr/bin之类的子目录时,强制NFS检查父目录的权限(默认)
no_subtree_check|和上面相对,不检查父目录权限
all_squash|共享文件的UID和GID映射匿名用户anonymous,适合公用目录。
no_all_squash|保留共享文件的UID和GID(默认)
root_squash|root用户的所有请求映射成如anonymous用户一样的权限(默认)
no_root_squas|root用户具有根目录的完全管理访问权限
anonuid=xxx|指定NFS服务器/etc/passwd文件中匿名用户的UID
systemctl enable nfs rpcbind
systemctl start nfs rpcbind
创建PV
创建 yaml 文件
vim tomcat-log-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: tomcat
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
nfs:
path: /home/bsh/nfs/tomcat-log
server: 10.0.10.51
创建 pv
kubectlapply-ftomcat-log-pv.yaml
查看pv
[root@master ]# kubectlgetpv
NAMECAPACITYACCESS MODESRECLAIM POLICYSTATUSCLAIMSTORAGECLASSREASONAGE
tomcat1GiRWXRetainAvailable26s
pv 属性详解
PV的存储容量
PV 将具有特定的存储容量。这是使用PV的capacity属性设置的。
目前,存储大小是可以设置或请求的唯一资源。未来的属性可能包括 IOPS、吞吐量等。
PV的访问模式
PersistentVolume可以以资源提供者支持的任何方式挂载到主机上。如下表所示,供应商具有不同的功能,每个 PV 的访问模式都将被设置为该卷支持的特定模式。例如,NFS 可以支持多个读/写客户端,但特定的 NFS PV 可能以只读方式导出到服务器上。每个 PV 都有一套自己的用来描述特定功能的访问模式。
存储模式包括:
- ReadWriteOnce——该卷可以被单个节点以读/写模式挂载
- ReadOnlyMany——该卷可以被多个节点以只读模式挂载
- ReadWriteMany——该卷可以被多个节点以读/写模式挂载
在命令行中,访问模式缩写为: - RWO - ReadWriteOnce
- ROX - ReadOnlyMany
- RWX - ReadWriteMany
一个卷一次只能使用一种访问模式挂载,即使它支持很多访问模式。例如,GCEPersistentDisk 可以由单个节点作为 ReadWriteOnce 模式挂载,或由多个节点以 ReadOnlyMany 模式挂载,但不能同时挂载
PV的回收策略
persistentVolumeReclaimPolicy属性用来指定PV的回收策略
- Retain(保留)——手动回收
- Recycle(回收)——基本擦除(rm -rf /thevolume/*)
- Delete(删除)——关联的存储资产(例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷)将被删除
当前,只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持删除策略。
PersistentVolumeClaim(PVC)
PersistentVolumeClaim
(PVC)是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源,PVC 消耗 PV 资源。Pod 可以请求特定级别的资源(CPU 和内存)。声明可以请求特定的大小和访问模式(例如,可以以读/写一次或 只读多次模式挂载)。创建PVC
创建 yaml 文件
vim tomcat-log-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: tomcat
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
创建 pv
kubectlapply-ftomcat-log-pvc.yaml
查看pv
[root@master ]# kubectlget pvc
NAMESTATUSVOLUMECAPACITYACCESS MODESSTORAGECLASSAGE
tomcatBoundtomcat1GiRWX18s
使用PVC
vim tomcat.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: tomcat-deployment
labels:
app: tomcat
spec:
replicas: 3
selector:
matchLabels:
app: tomcat
minReadySeconds: 1
progressDeadlineSeconds: 60
revisionHistoryLimit: 2
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: tomcat
spec:
containers:
- name: tomcat
image: wenlongxue/tomcat:tomcat-demo-62-8fe6052
imagePullPolicy: Always
ports:
- containerPort: 8080
resources:
requests:
memory: "2Gi"
cpu: "80m"
limits:
memory: "2Gi"
cpu: "80m"
readinessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 180
periodSeconds: 5
timeoutSeconds: 3
successThreshold: 1
failureThreshold: 30
volumeMounts:
- mountPath: "/usr/local/tomcat/logs"
name: tomcatvolumes:
- name: tomcat
persistentVolumeClaim:
claimName: tomcat
部署查看 pod
# 部署
kubectlapply-f tomcat.yaml
# 查看
kubectlgetpods |greptomcat
tomcat-deployment-7588b5c8fd-4grh21/1Running031s
tomcat-deployment-7588b5c8fd-l89t71/1Running031s
tomcat-deployment-7588b5c8fd-mb8bh1/1Running031s
最后【kubernetes 使用 PV 和 PVC 管理数据存储】PVC 不关心后端存储提供者是 NFS 还是 GFS,具体使用哪种类型的存储由 PV 来定义,PVC 只和隐藏了存储实现细节的 PV 对接。
本方式为静态分配,如果有一千个 Pod,每个 Pod 有一个 PVC,那么管理员需要人工开设一千个 PV,随着集群规模的扩大,将导致无法有效管理。
K8S 提供了一种可以动态分配的工作机制,可以自动创建 PV,该机制依赖一个叫做 StorageClass 的 API 对象。
文章链接
推荐阅读
- HarmonyOS JS应用开发需要关注哪些线程(官方解析来啦~)
- 简单的三步教你下载PyCharm汉化插件,让你学习Python事功半倍
- 揭秘盒马鲜生 Android 短视频秒播优化方案
- 免费教程STM32MP157之FreeRTOS系统篇2(FreeRTOS 互斥信号量)
- ReScript 与 TypeScript,谁是前端圈的“当红辣子鸡”
- 8.30-9.5上周精彩回顾
- netty系列之:搭建HTTP上传文件服务器
- Base 64 原理
- Flink 流处理