学ui+wordpress模板,北京推广优化,网站建设推广费用,windows 上wordpress文章目录 k8s之PV、PVC一、存储卷1、存储卷定义2、存储卷的作用2.1 数据持久化2.2 数据共享2.3 解耦2.4 灵活性 3、存储卷的分类3.1 emptyDir存储卷3.1.1 定义3.1.2 特点3.1.3 用途3.1.4 示例 3.2 hostPath存储卷3.2.1 定义3.2.2 特点3.2.3 用途3.2.4 示例 3.3 NFS存储卷3.3.1 … 文章目录 k8s之PV、PVC一、存储卷1、存储卷定义2、存储卷的作用2.1 数据持久化2.2 数据共享2.3 解耦2.4 灵活性 3、存储卷的分类3.1 emptyDir存储卷3.1.1 定义3.1.2 特点3.1.3 用途3.1.4 示例 3.2 hostPath存储卷3.2.1 定义3.2.2 特点3.2.3 用途3.2.4 示例 3.3 NFS存储卷3.3.1 定义3.3.2 特点3.3.3 用途3.3.4 示例 二、PV与PVC1、PV与PVC的定义1.1 PV1.1.1 定义1.1.2 关键信息 1.2 PVC1.2.1 定义1.2.2 关键信息 2、PV的状态3、PV从创建到销毁的过程 三、PV与PVC的关系1、PV与PVC2、PV和PVC之间的相互作用的生命周期 四、实现过程1、建立共享目录2、定义PV2.1 查看定义字段2.2 查看pv.spec可设置字段2.3 创建PV 3、定义PVC3.1 查看定义字段3.2 创建PVC 4、创建pod 五、动态PV1、动态pv的定义1.1 StorageClass1.2 Provisioner1.3 NFS-CLIENT-PROVISIONER 2、动态PV的作用3、动态PV的使用流程4、实现动态PV4.1 创建共享目录4.2 部署NFS-CLIENT-PROVISIONER4.3 创建Service Account 5、创建NFS Provisioner5.1 基本介绍5.2 创建 6、创建StorageClass7、创建PVC7.1 关闭自链接7.2 创建PVC 8、验证总结VolumePV和PVCPVPVC 静态PV的使用StorageClass——动态存储动态创建PV的过程 k8s之PV、PVC
一、存储卷
1、存储卷定义
存储卷是Kubernetes中的一个重要概念它为容器提供了持久化存储或其他类型的存储的能力。Pod中的容器可以通过存储卷来访问文件系统存储数据。存储卷的类型有很多如emptyDir、hostPath、NFS等。这些存储卷类型都有其特定的用途和限制
2、存储卷的作用
2.1 数据持久化
当Pod中的容器因为各种原因如升级、故障等被销毁或重启时存储在容器内的数据通常会丢失。通过使用存储卷可以将数据存储在Pod生命周期之外的位置确保数据即使在容器或Pod重启后仍然可用。
2.2 数据共享
存储卷允许多个容器在Pod内部共享数据。这对于需要共享配置、日志或其他数据的容器来说非常有用。通过挂载相同的存储卷不同的容器可以访问并修改其中的数据。
2.3 解耦
通过将数据存储在存储卷中而不是直接存储在容器内部可以实现应用与数据之间的解耦。这意味着应用的代码和数据可以分开管理从而简化应用的部署、升级和备份过程。
2.4 灵活性
Kubernetes支持多种类型的存储卷包括emptyDir、hostPath、NFS等。这为用户提供了很大的灵活性可以根据应用的需求选择最适合的存储解决方案。
还有一些其它的特性如 安全性通过使用只读存储卷可以限制容器对数据的修改权限从而提高数据的安全性。此外一些存储卷类型如加密云存储还可以提供额外的数据保护功能。 可移植性存储卷的使用使得应用在不同Kubernetes集群之间的迁移变得更加容易。只要目标集群支持相同的存储卷类型并且已经配置了相应的存储资源就可以轻松地将应用及其数据迁移到新的环境中。 日志和监控存储卷可以用于存储应用的日志和监控数据。通过将日志和监控数据写入存储卷中可以长期保存这些数据并使用专门的日志和监控工具进行分析和警报。
3、存储卷的分类
3.1 emptyDir存储卷
3.1.1 定义
emptyDir是Kubernetes中一种最简单的存储卷类型其生命周期与Pod相同。当Pod被分配给某个节点时会为该Pod创建一个emptyDir卷并且只要Pod在该节点上运行卷就一直存在。一旦Pod被删除emptyDir卷中的数据也会被永久删除
3.1.2 特点 生命周期 emptyDir 提供的存储是临时的其生命周期与所属的 Pod 相关。 emptyDir的生命周期与Pod相同即当Pod被删除时emptyDir也会被删除。 Pod 内容器之间的共享 emptyDir 在同一个 Pod 中的所有容器之间共享容器可以读写其中的数据。 存储位置 emptyDir存储卷位于Pod所在节点的本地文件系统中
3.1.3 用途
适用于需要在同一个 Pod 中的多个容器之间进行临时数据交换或共享的场景。如可以用于容器间的缓存共享、临时文件存储等用途。
3.1.4 示例
在yaml文件中定义emptyDir存储卷属性
mkdir -p /data/volumes
#新建目录cd /data/volumes/
#切换目录#编辑yaml配置文件
vim pod-emptydir.yaml
apiVersion: v1
#指定Kubernetes API 的版本
kind: Pod
#指定创建的资源类型为Pod
metadata:
#定义pod元信息name: pod-emptydir#指定pod的名称
spec:
#定义Pod的期望状态。containers:#定义Pod中要运行的容器- name: myapp#指定容器名称为myappimage: soscscs/myapp:v1#指定镜像imagePullPolicy: IfNotPresent#指定镜像拉取策略优先使用本地镜像本地没有则会拉取镜像ports:#定义端口列表- name: http#指定端口名称为httpcontainerPort: 80#指定容器暴漏端口为80volumeMounts:#定义容器要挂载的卷- name: html#这是卷的名称与下面的volumes部分中定义的卷名称相对应mountPath: /usr/share/nginx/html#容器内部的挂载路径- name: centos#指定容器名称centosimage: centos:7#指定镜像imagePullPolicy: IfNotPresent#指定镜像拉取策略volumeMounts:#定义容器要挂载的卷- name: html#同样定义卷的名称与volumes部分定义的名称一致mountPath: /data/#容器内部的挂载路径command: [/bin/sh,-c,while true;do echo $(date %F--%H:%M:%S) /data/index.html;sleep 2;done]#容器内部执行的命令使用死循环语句每两秒输出时间格式为%F(年、月、日)--%H(时):%M(分):%S(秒)到挂载的文件volumes:#定义了 Pod 中的卷- name: web#卷的名称与上面的volumeMounts部分中定义的名称相对应emptyDir: {}#这定义了一个空目录卷。Pod 中的所有容器都可以访问这个卷
#当Pod被删除时这个卷也会被删除。空目录卷通常用于临时存储例如在Pod中的容器之间共享数据--------------------------------------------------------------------------------------------------------
说明
最下方volumes定义了一个名为html的卷类型为emptyDir。emptyDir是一个临时卷它的生命周期与Pod相同。当Pod被分配给节点时会创建一个空的卷emptyDir: {}并且只要Pod运行在该节点上卷就一直存在。如果Pod从节点上删除无论是由于某些错误还是正常的删除操作则卷中的数据也会被永久删除。nginxsoscscs/myapp:v1容器将html卷emptyDir: {}挂载到/usr/share/nginx/html路径下。centos容器将html卷emptyDir: {}挂载到/data/路径下。因此当这个Pod被创建并运行后两个容器都可以访问和修改html卷emptyDir: {}中的数据。这可以用于共享数据、配置文件、日志文件等。但是由于emptyDir是临时的所以一旦Pod被删除这些数据也会丢失--------------------------------------------------------------------------------------------------------kubectl apply -f pod-emptydir.yaml
#创建资源kubectl get pods -owide -w
#查看pod资源详细信息curl 10.244.2.111
#访问ip
#在上面yaml文件中定义了2个容器其中一个容器是输入日期到index.html中然后验证访问nginx的html是否可以获取日期。以验证两个容器之间挂载的emptyDir实现共享。3.2 hostPath存储卷
3.2.1 定义
hostPath卷将主机节点文件系统中的文件或目录挂载到Pod中。hostPath可以实现持久存储但是在node节点故障时也会导致数据的丢失。
3.2.2 特点
直接访问主机文件系统 HostPath存储卷允许Pod直接访问主机节点上的文件系统提供了对主机存储的直接访问权限。读写权限 Pod可以对HostPath上的文件进行读写操作这为一些需要在容器内进行文件操作的应用提供了便利。节点依赖性 Pod使用HostPath时会依赖节点上的具体路径这可能导致在不同节点上部署相同Pod时出现问题因为节点之间的文件系统路径可能不同。共享资源多个Pod可以共享同一个HostPath但要小心避免数据冲突或竞争条件。
3.2.3 用途
主机文件操作 适用于需要在Pod内进行主机文件系统操作的场景例如读取或写入主机上的特定文件。数据共享 多个Pod可以共享同一个HostPath这在一些需要多个Pod之间共享数据的情况下可能很有用。特殊需求 用于满足一些特殊需求例如某些应用需要在容器内直接操作主机上的某些文件。
3.2.4 示例
创建pod资源信息
kubectl delete -f pod-emptydir.yaml
#删除之前创建的容器#编辑yaml配置文件
vim pod-hostpath.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-hostpath
spec:containers:- name: nginximage: nginx:1.18.0imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80volumeMounts:#定义如何在容器内部挂载存储卷- name: html #指定要挂载的存储卷的名称volumes.name字段定义的名称mountPath: /usr/share/nginx/html#容器内部的目录路径存储卷将被挂载到这个路径上readOnly: false#false表示容器可以读写该存储卷volumes:#定义宿主机上的目录文件为Pod中可用的存储卷- name: html#自定义存储卷的名称hostPath:#指定存储卷类型为hostPathpath: /data/html/nginx/#指定宿主机上可以挂载到pod中的目录或文件type: DirectoryOrCreate#指定hostPath的类型DirectoryOrCreate表示不存时创建
--------------------------------------------------------------------------------------------------------
readOnly
#如果设置为true则容器以只读方式挂载的存储卷如果设置为false或空值则容器可以读写该存储卷hostPath
#允许将主机上的文件系统目录或文件挂载到Pod中type 可设置的类型值
# (默认)不进行任何特殊处理。
#DirectoryOrCreate如果指定路径下的目录不存在则创建它。
#Directory目录必须存在。
#FileOrCreate如果指定路径下的文件不存在则创建它。
#File文件必须存在。
#SocketUNIX套接字必须存在。
#CharDevice字符设备必须存在。
#BlockDevice块设备必须存在
--------------------------------------------------------------------------------------------------------kubectl apply -f pod-hostpath.yaml
#创建资源kubectl get pods -owide
#查看pod资源详细信息此pod在node02节点上创建在node02节点查看文件
cd /data/html/nginx/
#切换目录echo this is hostpath index.html
#创建访问页面因为是将宿主机上的目录挂载到pod上会覆盖挂载点(/usr/share/nginx/html)下的文件curl 10.244.2.112
#访问验证删除pod由于文件是在宿主机上hostPath存储卷模式下不会删除节点上的文件
kubectl delete -f pod-hostpath.yaml
#删除容器node02节点查看
cat index.html
#删除容器之后到之前的node节点依然可以访问之前创建的页面--------------------------------------------------------------------------------------------------------
#需要注意的是当宿主机即node节点发生故障时数据仍会丢失且hostPath卷直接引用主机上的文件或目录因此它可能会暴露敏感数据或允许Pod执行不受限制的操作。在生产环境中通常建议使用更安全的存储解决方案如持久卷PersistentVolumes或云提供商提供的存储服务。#当pod生命周期结束后创建新的pod只要是指定挂载此存储卷依然可以访问到数据#hostPath会自动优先选择合适的节点如node02上有指定的挂载路径则不需要再去node01节点上创建会自动选择带有指定挂载路径的节点
--------------------------------------------------------------------------------------------------------3.3 NFS存储卷
3.3.1 定义
在Kubernetes中NFS共享存储卷是一种常见的持久化存储解决方案它允许多个Pod在集群中共享同一个NFS服务器上的存储空间。
NFS介绍 NFSNetwork File System是一种基于网络的文件系统协议允许在网络上共享文件系统资源。它使得不同的计算机之间可以像访问本地文件一样访问远程文件。Kubernetes中的NFS存储卷 Kubernetes提供了多种方式来使用NFS作为持久化存储卷。其中一种常见的方法是使用NFS卷插件例如NFS CSI Driver它能够与Kubernetes集成并提供对NFS存储的访问。配置NFS存储卷 要在Kubernetes中配置NFS存储卷首先需要在NFS服务器上设置共享目录并确保NFS服务器可以通过网络访问。然后可以通过Kubernetes的PersistentVolumePV和PersistentVolumeClaimPVC对象来声明和使用NFS存储卷。
3.3.2 特点
共享性 NFS存储卷允许多个Pod在集群中共享同一个NFS服务器上的存储空间。这使得多个应用程序可以访问和操作相同的数据促进了数据共享和协作。持久性 NFS存储卷提供了持久化的存储解决方案数据存储在NFS服务器上并且在Pod重新启动或迁移时仍然可用。这对于需要长期保存数据的应用程序和服务非常有用。可扩展性 NFS存储卷可以轻松地扩展以满足应用程序的需求。通过在NFS服务器上添加更多的存储空间或者增加NFS服务器的数量可以扩展存储容量和性能。灵活性 使用NFS存储卷可以将存储与Pod分离从而使得Pod可以在不同的节点上迁移而不会丢失数据。这种灵活性使得在Kubernetes集群中部署和管理应用程序变得更加容易。
3.3.3 用途
简化管理 NFS存储卷可以通过Kubernetes的PV和PVC对象进行声明和管理而无需手动管理存储配置。这简化了存储管理的流程并提高了部署和维护的效率。适用范围广泛 NFS存储卷适用于许多不同类型的应用程序和场景包括数据库、文件共享、日志存储等。它提供了一种通用的存储解决方案适用于各种不同的业务需求。
3.3.4 示例
首先搭建NFS共享服务器并指定共享目录在nfs服务器上操作
mkdir -p /data/volumes
#创建共享目录chmod 777 /data/volumes/
#添加权限echo this is nfs /data/volumes/index.html
#创建共享目录并添加权限自定义访问界面vim /etc/exports
/data/volumes/ 192.168.10.0/24(rw,no_root_squash)
#添加共享目录信息及权限到/etc/exports文件中进行共享systemctl start rpcbind
systemctl start nfs
#启动共享服务未安装时先进行安装ss -natp |grep rpcbind
#RPC端口远程连接ss -natp |grep 2049
#NFS端口提供服务任意节点查看共享情况
showmount -e 192.168.10.14
#任意节点查看nfs目录共享定义nfs存储卷文件
#编辑yaml配置文件定义存储文件
vim pod-nfs.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-nfs#pod的名称
spec:containers:- name: nginx#容器的名称image: nginx:1.18.0imagePullPolicy: IfNotPresent#镜像拉取策略ports:- name: httpcontainerPort: 80volumeMounts:- name: nfsmountPath: /usr/share/nginx/html#容器内挂载卷的路径readOnly: falsevolumes:#Pod级别的卷定义- name: nfsnfs:#指定使用nfs存储卷path: /data/volumes#指定nfs服务器的共享目录server: 192.168.10.14#指定挂载的nfs服务器地址映射后也可以写主机名创建pod后访问容器就可以访问到自定义的web界面
kubectl apply -f pod-nfs.yaml
#创建pod资源kubectl get pods -owide
#查看pod资源详细信息#访问
curl 10.244.2.113
this is nfs#同样的删除pod后重新创建只要使用nfs挂载此文件可以得到数据的持久化存储。
#但是容易发生单点故障服务器宕机时所有客户端无法访问多台客户端挂载在同一台服务器上管理维护较繁琐总结
emptyDir、hostPath和NFS是Kubernetes中三种不同的存储卷类型它们各自具有不同的特点和用途 emptyDir适用于临时数据和需要共享数据的Pod hostPath适用于需要访问宿主机文件系统的特殊场景 NFS则是一种网络存储解决方案可以实现数据的跨节点共享和访问。
二、PV与PVC
在Kubernetes中存储卷Volumes是Pod中可以访问的存储的抽象用于存储数据。然而随着Kubernetes集群的复杂性和多租户的需求增长仅仅依赖Pod中的存储卷定义已经不足以满足所有存储需求。为了解决这个问题Kubernetes引入了PersistentVolumePV和PersistentVolumeClaimPVC的概念它们为存储资源提供了更高层次的管理和抽象
1、PV与PVC的定义
1.1 PV
1.1.1 定义
PVPersistent Volume是对底层的共享存储的一种抽象它由管理员进行创建和配置。PV是与具体的底层共享存储技术的实现方式相关的例如Ceph、GlusterFS、NFS等它们通过插件机制完成与共享存储的对接实现数据持久化存储。
1.1.2 关键信息
PV作为对存储资源的定义主要涉及存储能力即存储空间的大小、访问模式如ReadWriteOnce、ReadOnlyMany、ReadWriteMany等、存储类型、回收策略以及后端存储类型等关键信息的设置。
1.2 PVC
1.2.1 定义
PVCPersistent Volume Claim是用户对存储的一种声明它与Pod比较类似。Pod消耗的是节点资源而PVC消耗的是PV资源。PVC可以请求特定的存储空间和访问模式而不需要用户关心底层的存储实现细节。
1.2.2 关键信息
PVC主要涉及存储空间请求、访问模式、PV选择条件和存储类别等信息的设置。当PVC被创建时Kubernetes会尝试将其与满足其要求的PV进行绑定。如果系统中存在一个DefaultStorageClass那么在创建PVC的时候可以不指定storageClassName系统会自动使用默认的存储类型。
2、PV的状态
Available可用PV已经被创建但尚未被绑定到任何PVC上因此可以被任何PVC请求使用。Bound已绑定PV已经被绑定到一个PVC上可以被挂载到一个Pod中使用。Released已释放PVC与PV之间的绑定关系已经被删除但是PV上的数据还未被清除。此时PV处于Released状态可以被重新绑定到另一个PVC上使用。Failed失败PV与底层存储后端的连接出现问题或者存储后端出现了错误导致PV无法使用。此时PV处于Failed状态。
3、PV从创建到销毁的过程
PVPersistent Volume从创建到销毁的过程通常包括以下几个步骤
创建ProvisioningPV可以通过两种方式创建一种是静态创建另一种是动态创建。静态创建是指管理员手动创建PV对象并指定其属性如存储类型、大小等。动态创建则是通过StorageClass进行配置当PVC请求存储资源时根据StorageClass的定义动态创建PV。无论是静态还是动态创建都会生成一个PV对象。状态会变成Available等待被PVC绑定绑定BindingPV需要与PVC进行绑定才能被使用。管理员或Kubernetes系统会将某个PV绑定到一个特定的PVC上使其成为PVC的存储资源状态会变成Bound就可以被定义了相应PVC的Pod使用。使用Using一旦PV被绑定到PVC上Pod可以通过PVC来使用PV提供的存储资源。Pod会挂载PVC从而访问PV中的数据。释放Releasing当PVC不再需要PV提供的存储资源时管理员或Kubernetes系统会将PV与PVC之间的绑定解除释放PVPV的状态变成Released。这并不会立即删除PV中的数据而是将PV标记为已释放状态。回收Recycling在PV被释放后根据管理员或系统配置的策略可以选择回收PV。回收的方式可能包括保留PV以备下次使用或者直接删除PV以释放资源。有三种回收策略Retain、Delete和Recycle。Retain就是保留现场K8S集群什么也不做等待用户手动去处理PV里的数据处理完后再手动删除PV。Delete策略K8S会自动删除该PV及里面的数据。Recycle方式K8S会将PV里的数据删除然后把PV的状态变成Available又可以被新的PVC绑定使用。
三、PV与PVC的关系
1、PV与PVC 在 Pod 中定义一个存储卷该存储卷类型为 PVC定义的时候直接指定大小PVC 必须与对应的 PV 建立关系PVC 会根据配置的定义去 PV 申请而 PV 是由存储空间创建出来的。PV 和 PVC 是 Kubernetes 抽象出来的一种存储资源 简单来说类似于LVM逻辑卷LVM逻辑卷是将磁盘整合建立卷组而后根据卷组建立逻辑卷并指定使用空间的大小 而PV就是将共享服务器例如NFS、CEPH等进行划分建立一个或多个PV存储卷PVC指定挂载存储卷的大小及访问模式读、写挂载对应的PV卷达到数据持久化存储
2、PV和PVC之间的相互作用的生命周期
Provisioning配置: PV的创建阶段可通过静态方式直接创建PV或使用StorageClass进行动态创建。Binding绑定: 将PV分配给对应的PVC。Using使用: Pod通过PVC使用Volume通过准入控制StorageProtection1.9及以前版本为PVCProtection可以阻止删除正在使用的PVC。Releasing释放: Pod释放Volume并删除PVC。Recycling回收: 回收PV可保留PV以备下次使用或直接从云存储中删除。
Provisioning--- Binding--- Using--- Releasing --- Recycling ● Provisioning创建即 PV 的创建可以直接创建 PV静态方式也可以使用 StorageClass 动态创建● Binding绑定将 PV 分配给 PVC● Using使用Pod 通 PVC使用该 Volume并可以通过准入控制StorageProtection1.9及以前版本为PVCProtection 阻止删除正在使用的 PVC● Releasing释放Pod 释放 Volume 并删除 PVC● Reclaiming回收 PV可以保留 PV 以便下次使用也可以直接从云存储中删除四、实现过程
以NFS共享服务器为例 首先在NFS服务器上建立共享目录 建立PV卷定义PV卷的大小与访问模式 创建PVS请求是PVC与PC之间建立联系 创建pod指定需要使用的PVC
静态PV 静态PV就是手动创建PV然后等待PVC请求建立连接 NFS使用PV与PVC
1、建立共享目录
nfs服务器上操作创建共享目录
cd /data/volumes/
#切换目录mkdir pv{1..4}
#创建目录#添加共享目录
vim /etc/exports
/data/volumes/pv1 192.168.10.0/24(rw,no_root_squash)
/data/volumes/pv2 192.168.10.0/24(rw,no_root_squash)
/data/volumes/pv3 192.168.10.0/24(rw,no_root_squash)
/data/volumes/pv4 192.168.10.0/24(rw,no_root_squash)exportfs -avr
#重新导出/etc/ecports文件中定义的共享目录showmount -e
#查看nfs服务器的所有共享目录2、定义PV
2.1 查看定义字段
使用kubectl explain查看pv的定义方式
#查看PV的定义方式
kubectl explain pv
KIND: PersistentVolume
VERSION: v1apiVersion string#设置为v1即可通用版本kind string#设置PV卷kind的值为PersistentVolumemetadata Object#PV是集群级别的资源可以跨namespace所以不需要指定spec Object#定义PV的特性status Object#状态创建后自动生成一般不需要配置2.2 查看pv.spec可设置字段
#查看pv.spec可设置字段
kubectl explain pv.spec
...
---------------------accessModes ([string] 类型)-------------------------------------------------------
定义了卷的访问模式。PV 可以被单个节点以某种方式访问或者被多个节点以某种方式访问。
可能的值有
ReadWriteOnce (RWO): 卷可以被单个节点以读写模式挂载。
ReadOnlyMany (ROX): 卷可以被多个节点以只读模式挂载。
ReadWriteMany (RWX): 卷可以被多个节点以读写模式挂载。
#注意nfs支持三种访问模式但是不是所有的存储类型都支持所有的访问模式。
#例如iSCSI不支持ReadWriteManyHostPath不支持ReadOnlyMany和ReadWriteMany
--------------------------------------------------------------------------------------------------------
---------------------------------capacity ------------------------------------------------------------
描述了 PV 的存储容量。通常包含一个条目键为storage值为存储容量大小
如storage: 1Gi
-------------------------------------------------------------------------------------------------------------------------------------------nfs----------------------------------------------------------------
定义存储卷类型为nfs以下常用两个字段
path: 定义挂载卷路径
server: 定义服务器名称
-------------------------------------------------------------------------------------------------------------------------persistentVolumeReclaimPolicy (string 类型)-------------------------------------------
当 PV 不再被 PVC 引用时即 PVC 被删除此字段定义了 PV 的回收策略
Retain: 手动回收保留 PV需要管理员手动处理。
Recycle: 基本弃用只有 NFS 和 HostPath 支持
Delete: 删除与 PV 关联的存储资源。
---------------------------------------------------------------------------------------------------------------------------------------storageClassName-------------------------------------------------------
自定义存储类名称此配置用于绑定具有相同类别的PVC和PV
如果 PV 属于某个 StorageClass则该字段将包含 StorageClass 的名称。
PVC 可以请求特定 StorageClass 的 PV。
----------------------------------------------------------------------------------------------------------------------------------volumeMode (string 类型)-----------------------------------------------------
指定了卷的模式可以是文件系统或块设备。
Filesystem: PV 作为文件系统挂载到容器中。
Block: PV 作为原始块设备挂载到容器中通常用于数据库等需要直接访问块设备的场景。--------------------------nodeAffinity (Object)-------------------------------------------------------
描述了 PV 对节点的亲和性规则。
--------------------------------------------------------------------------------------------------------
......2.3 创建PV
定义4个PV分别定义挂载的路径以及访问模式还有PV划分的大小。
#编辑yaml配置文件
vim pod-pv.yaml
apiVersion: v1
kind: PersistentVolume
#定义了资源的类型为PersistentVolume
metadata:name: pv01labels:name: pv01
spec:
#这是PV的规格描述nfs:#指定了PV的后端存储类型为NFSpath: /data/volumes/pv1#NFS服务器上存储卷的路径server: 192.168.10.14#NFS服务器的IP地址accessModes: [ReadWriteMany,ReadWriteOnce]#定义PV的访问模式为两种RWX,RWOcapacity:#定义PV容量storage: 1Gi#指定PV存储容量为1GiB
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv02labels:name: pv02
spec:nfs:path: /data/volumes/pv2server: 192.168.10.14accessModes: [ReadWriteOnce]#定义PV的访问模式为RWOcapacity:storage: 2Gi#指定PV存储容量为2GiB
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv03labels:name: pv03
spec:nfs:path: /data/volumes/pv3server: 192.168.10.14accessModes: [ReadWriteMany,ReadWriteOnce]#定义PV的访问模式为两种RWX,RWOcapacity:storage: 2Gi#指定PV存储容量为2GiB
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv04labels:name: pv04
spec:nfs:path: /data/volumes/pv4server: 192.168.10.14accessModes: [ReadWriteMany,ReadWriteOnce]#定义PV的访问模式为两种RWX,RWOcapacity:storage: 3Gi#指定PV存储容量为3GiB查看创建结果
kubectl apply -f pod-pv.yaml
#创建资源kubectl get pv
#查看pv资源3、定义PVC
3.1 查看定义字段
#查看pvc定义字段
kubectl explain pvc
......apiVersion: v1
kind: PersistentVolumeClaim
metadata
spec
status
.....#apiVersion、metadata、status字段与pv基本一致kind字段设置为PersistentVolumeClaim查看pvc.spec下的字段
kubectl explain pvc.spec
#查看pvc.spec下的字段---------------------accessModes ([string] 类型)-------------------------------------------------------
描述用户应用对存储资源的访问权限
ReadWriteOnce (RWO): 卷可以被单个节点以读写模式挂载。
ReadOnlyMany (ROX): 卷可以被多个节点以只读模式挂载。
ReadWriteMany (RWX): 卷可以被多个节点以读写模式挂载。
#注意nfs支持三种访问模式但是不是所有的存储类型都支持所有的访问模式。
#例如iSCSI不支持ReadWriteManyHostPath不支持ReadOnlyMany和ReadWriteMany
----------------------------------------------------------------------------------------------------------------------------------------volumeMode------------------------------------------------------------
描述希望使用的 PV 存储卷模式。
可以是文件系统 (Filesystem) 或裸格式的块设备 (Block)。
------------------------------------------------------------------------------------------------------------------------------------resources (Object)--------------------------------------------------------
描述对存储资源的请求。定义申请资源的大小
目前仅支持设置 requests.storage即对存储空间的设置。
---------------------------------------------------------------------------------------------------------------------------------storageClassName (string)----------------------------------------------------
定义存储类名称此配置用于绑定具有相同类别的PVC和PV
如果有多个 PV 符合 PVC 的要求Kubernetes 会基于 PVC 指定的StorageClass来选择 PV
------------------------------------------------------------------------------------------------------------------------------------selector (Object)---------------------------------------------------------
一个可选字段用于更精细地选择 PV。
可以通过 matchLabels 和 matchExpressions 来选择具有特定标签的 PV。
--------------------------------------------------------------------------------------------------------3.2 创建PVC
定义的spec关键字段如存储大小访问模式、存储类型需要与PV信息匹配
#编辑yaml配置文件
vim pod-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
#指定资源类型为PersistentVolumeClaim即PVC
metadata:name: pvc01
spec:accessModes: [ReadWriteMany]#定义期望获得的访问模式为ReadWriteMany,即RWXresources:#描述 PVC 的资源需求requests:#列出PVC所请求的特定资源storage: 2Gi#指定PVC所请求的存储容量。指定为2Gi那么就会匹配存储容量为2Gi的PVkubectl apply -f pod-pvc.yaml
#创建资源kubectl get pv
#查看创建结果------------------------------------------------------------------------------------------------------
PV 的状态STATUS有以下 4 种
- Available可用表示可用状态还未被任何 PVC 绑定
- Bound已绑定表示 PV 已经绑定到 PVC
- Released已释放表示 PVC 被删掉但是资源尚未被集群回收
- Failed失败表示该 PV 的自动回收失败
------------------------------------------------------------------------------------------------------4、创建pod
定义创建pod的yaml文件并定义pvc挂载存储
#编辑yaml配置文件
vim pod-pv01.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-pvnamespace: default
spec:containers:- name: nginximage: nginx:1.18.0volumeMounts:- name: html#指定要挂载的存储卷名称与volumes.name字段设置的一致mountPath: /usr/share/nginx/html#将volumes字段设置的存储卷挂载到该路径下volumes:- name: html#定义存储卷名称persistentVolumeClaim:#定义存储卷是由PersistentVolumeClaim(PVC)提供claimName: pvc01#指定PVC名称的pvc01kubectl apply -f pod-pv01.yaml
#创建pod资源kubectl get pods pod-pv -owide
#查看pod资源详细信息在nfs服务器上创建访问页面NFS服务器操作
cd /data/volumes/pv3
#切换到PVC绑定的路径echo this is pv3 index.html
#编辑访问页面master节点curl 10.244.2.199
#访问pod就可以看到自定义的访问界面此时就可以实现存储数据的持久化哪怕pod意外中断退出或手动删除以后数据依旧会保存在NFS服务器上。但是此时因为手动创建了四个PV而且是PVC是指定已经存在的PV并匹配对应的PV资源类型如果面对庞大的PVC请求且请求的资源类型与访问模式不同如果设置的是静态PV那么就需要手动创建一个个对应的请求这是一个庞大的工作量想要解决这个问题就需要设置动态PV
五、动态PV
1、动态pv的定义 动态PV是在集群级别使用StorageClass和Provisioner来自动创建PV对象的方式 Kubernetes 本身支持的动态PV创建但是不包括NFS所以需要使用外部存储卷插件分配PV。卷插件称为 Provisioner存储分配器NFS 使用的是 nfs-client这个外部PV。
1.1 StorageClass StorageClass为管理员提供了一种描述存储“类”Class的方法。它允许管理员定义不同的存储类别每个类别可能会映射到不同的服务质量等级、备份策略或其他存储相关的策略。 StorageClass为用户屏蔽了后端存储的细节用户只需指定StorageClass的名称而无需关心具体的存储实现。 基于StorageClassKubernetes可以动态地为PersistentVolumeClaimsPVCs创建PersistentVolumesPVs从而实现了动态的资源供应。
1.2 Provisioner
用于指定 Volume 插件的类型包括内置插件如 kubernetes.io/aws-ebs和外部插件如 exte卷插件会使用已经配置好的 NFS 服务器自动创建 rnal-storage 提供的 ceph.com/cephfs
1.3 NFS-CLIENT-PROVISIONER
Kubernetes的外部存储供应器provisioner依赖于NFS服务来动态地创建PV。因此在部署NFS-CLIENT-PROVISIONER之前需要确保NFS服务已经部署并正常运行
2、动态PV的作用
自动创建通过StorageClass指定存储的类型和配置由Provisioner自动创建和管理PV对象。无需手动配置与静态PV不同动态PV不需要管理员手动配置和管理PV资源。可扩展与动态分配适用于可扩展的、动态分配的存储资源用户只需声明所需的存储要求无需关心具体的存储配置和管理。
3、动态PV的使用流程 管理员首先定义一个StorageClass它描述了存储类的属性如存储类型、后端存储参数如NFS服务器的地址和路径、回收策略等。StorageClass中指定了Provisioner插件该插件负责根据StorageClass的定义动态创建PV 根据StorageClass中指定的Provisioner插件管理员需要在Kubernetes集群中安装并配置相应的插件 用户或应用开发者在Kubernetes集群中创建一个PVC指定所需的存储大小、访问模式以及StorageClass的名称 Kubernetes系统监控PVC的创建并查找与之匹配的StorageClass。一旦找到匹配的StorageClassKubernetes会触发Provisioner插件根据StorageClass的定义动态创建一个PV。 创建好的PV会自动与PVC进行绑定。这个绑定过程是基于PVC中的请求参数如存储大小和访问模式与PV的属性进行匹配的 当Pod创建时它可以指定使用某个已绑定的PVC。Kubernetes会将PV挂载到Pod中使得Pod中的应用可以访问该PV上的数据。
4、实现动态PV
创建之前清空之前的操作记录
kubectl delete -f pod-pv01.yaml
kubectl delete -f pod-pvc.yaml
kubectl delete -f pod-pv.yaml
#删除之前创建的资源
#删除时需要注意的是首先删除PVC因为PV一旦被占用则无法进行删除需要删除PVC释放PV资源4.1 创建共享目录
NFS服务器操作
mkdir /nfs/k8s
#创建目录chmod -R 777 /nfs/k8s/
#添加权限#编辑共享目录
vim /etc/exports
/nfs/k8s 192.168.10.0/24(rw,no_root_squash,sync)
#允许192.168.10.0/24网段的主机以读写模式挂载/nfs/k8s目录并且不进行root权限转换norootsquash并同步写入syncexportfs -avr
#重新加载配置showmount -e
#查看共享目录4.2 部署NFS-CLIENT-PROVISIONER 在所有node节点上部署NFS-CLIENT-PROVISIONER镜像 从Docker仓库或其他可信来源下载NFS-CLIENT-PROVISIONER的Docker镜像。并确保每个节点上都有NFS服务 镜像下载地址external-storage/nfs-client at master · kubernetes-retired/external-storage · GitHub 镜像包下载完毕后上传到node节点服务器并使用docker命令生成镜像
node01、node02节点
cd /data
#切换目录#上传需要的镜像文件nfs-client-provisioner.tardocker load -i nfs-client-provisioner.tar
#将镜像文件导入镜像库4.3 创建Service Account
在Kubernetesk8s集群中创建Service Account是为了管理NFS Provisioner在集群中运行时的权限。NFS Provisioner是用于动态创建Persistent VolumesPV和Persistent Volume ClaimsPVC的工具通常与StorageClass一起使用。设置nfs-client对PV、PVC和StorageClass的规则是确保NFS Provisioner在使用NFS共享存储时遵循一定的访问和权限规则。这可以包括定义NFS服务器地址、共享路径、访问权限等配置以便Kubernetes中的应用程序能够正确地使用NFS存储。通过Service Account的设置可以为NFS Provisioner分配适当的权限确保其能够成功管理和提供NFS存储服务。
# 创建 Service Account 账户用来管理 NFS Provisioner 在 k8s 集群中运行的权限
vim nfs-client-rbac.yaml
apiVersion: v1
kind: ServiceAccount
#指定资源类型为用户
metadata:name: nfs-client-provisioner#Service Account 的名称
---
#创建集群角色
apiVersion: rbac.authorization.k8s.io/v1
#表示使用的是RBAC API的版本1
kind: ClusterRole
#定义一个集群级别的角色
metadata:name: nfs-client-provisioner-clusterrole#集群角色的名称用于在Kubernetes集群中唯一标识
rules:
#ClusterRole中定义的具体权限列表- apiGroups: []#表示核心API组不包含任何前缀的API组resources: [persistentvolumes]#表示对持久卷PersistentVolumes的权verbs: [get, list, watch, create, delete]#verbs: 列出了可以执行的操作get(获取)、list(列表)、watch(监听)、create(创建)和delete(删除)- apiGroups: []resources: [persistentvolumeclaims]verbs: [get, list, watch, update]#第二个规则组与第一个规则类似但针对的是持久卷声明- apiGroups: [storage.k8s.io]#表示存储API组的名称resources: [storageclasses]#表示对存储类StorageClasses的权限。verbs: [get, list, watch]#列出了可以执行的操作但仅允许读取操作get、list和watch- apiGroups: []resources: [events]verbs: [list, watch, create, update, patch]#定义了对Kubernetes事件Events的权限- apiGroups: []resources: [endpoints]verbs: [create, delete, get, list, watch, patch, update]#定义了对端点Endpoints的广泛权限包括创建、删除、获取、列表、监听、补丁和更新
---
#集群角色绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
#定义了一个名为nfs-client-provisioner-clusterrolebinding的ClusterRoleBinding将前面定义的ClusterRole绑定到先前定义的Service Account上以确保该Service Account拥有相应的权限
metadata:name: nfs-client-provisioner-clusterrolebinding# 集群角色绑定的名称
subjects:
#定义了哪些用户或用户组会被授予权限
- kind: ServiceAccount
#定义了一个名为nfs-client-provisioner的Service Account用于代表NFS Provisioner在集群中运行时的身份name: nfs-client-provisioner#绑定的Service Account的名称namespace: default#所在的命名空间
roleRef:
#定义了该绑定所引用的ClusterRolekind: ClusterRole#定义了一个名为nfs-client-provisioner-clusterrole的ClusterRole包含了对于Persistent VolumesPV、Persistent Volume ClaimsPVC、StorageClasses等资源的访问权限规则。这些规则包括获取、列出、监视、创建和删除PV、PVC以及获取、列出、监视StorageClasses等操作。name: nfs-client-provisioner-clusterrole#所绑定的集群角色名称apiGroup: rbac.authorization.k8s.io#表示API组的名称对于ClusterRole它通常是rbac.authorization.k8s.io#这段YAML文件定义了在Kubernetes中创建一个Service Account以及相关的ClusterRole和ClusterRoleBinding来管理NFS Provisioner的权限。通过这些定义可以确保NFS Provisioner在Kubernetes集群中具有适当的权限以管理PV、PVC和StorageClasses等资源。kubectl apply -f nfs-client-rbac.yaml
#创建资源kubectl get serviceaccount/nfs-client-provisioner -owide
kubectl get clusterrole nfs-client-provisioner-clusterrole -owide
kubectl get clusterrolebindings nfs-client-provisioner-clusterrolebinding -owide
#查看新建资源的详细信息5、创建NFS Provisioner
5.1 基本介绍
NFS Provisioner是一个自动配置卷程序本质上就是一个pod其主要功能是利用现有的和已配置的NFS服务器来支持通过持久卷声明动态配置Kubernetes持久卷
NFS Provisione(即 nfs-client)有两个功能 NFS Provisioner能够自动为Kubernetes集群中的Pod提供NFS持久卷。在 NFS 共享目录下创建挂载点(volume)持久卷的名称遵循一定的格式通常是namespace-{pvcName}-${pvName}。 将 PV 与 NFS 的挂载点建立关联。
工作原理
当Kubernetes集群中的Pod需要访问NFS持久卷时通过持久卷声明PersistentVolumeClaim来请求。NFS Provisioner会监听这些声明并自动创建和配置相应的NFS持久卷
5.2 创建
使用Deployment创建nfs-client-provisioner防止因为它发生故障时退出导致NFS服务器无法使用
#编辑yaml配置文件
vim nfs-client-pro.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nfs-client-provisioner
spec:replicas: 1selector:matchLabels:app: nfs-client-provisionerstrategy:#指定更新Pod的策略type: Recreate#更新Deployment时将使用重建Recreate策略template:metadata:labels:app: nfs-client-provisionerspec:serviceAccountName: nfs-client-provisioner#指定Pod使用的ServiceAccount的名称containers:- name: nfs-client-provisionerimage: quay.io/external_storage/nfs-client-provisioner:latest#之前下载的镜像imagePullPolicy: IfNotPresentvolumeMounts:#定义容器内的挂载点挂载到什么位置- name: nfs-k8s#挂载卷名称、volumes定义的mountPath: /persistentvolumes#挂载到该路径env:#定义容器的环境变量。- name: PROVISIONER_NAME#变量名称配置provisioner的Namevalue: nfs-storage#变量值此值在建立StorageClass时使用- name: NFS_SERVER#变量名称指定NFS服务器value: 192.168.10.14#NFS服务器地址或主机名- name: NFS_PATH#变量名称指定共享目录value: /nfs/k8s#NFS共享目录volumes:#定义Pod中的卷- name: nfs-k8s#卷的名称与上面的volumeMounts定义中的名称相匹配nfs:#定义NFS卷的参数server: 192.168.10.14#NFS服务器的地址path: /nfs/k8s#NFS服务器上的共享路径----------------------------------------------------------------------------------------------------
Recreate重建: 使用此策略时Kubernetes会首先终止所有的旧Pods然后等待这些Pods都被
完全删除并清理后再创建新的Pods。这意味着在更新过程中服务可能会经历一段不可用时间因
为所有的Pods都会被同时替换。虽然这种方法可能导致服务中断但它有时更简单、更可靠特别是
当应用程序不支持滚动更新或者需要确保在更新过程中没有两个版本的Pods同时运行时。
----------------------------------------------------------------------------------------------------kubectl apply -f nfs-client-pro.yaml
#创建资源kubectl get deployments.apps nfs-client-provisioner
#查看deploy资源信息kubectl get pod
#查看pod资源信息6、创建StorageClass 负责建立 PVC 并调用 NFS provisioner 进行预定的工作并让 PV 与 PVC 建立关联 定义StorageClassStorageClass是Kubernetes中用于描述存储类的一种资源对象。通过定义StorageClass可以指定如何为PVC提供后端存储如NFS。 在StorageClass中可以指定Provisioner如NFS-CLIENT-PROVISIONER、存储类型、配置参数等。 StorageClass的作用当PVC被创建时Kubernetes会根据PVC的存储要求查找匹配的StorageClass并委托给相应的Provisioner来创建满足要求的PV。因此StorageClass是PVC和PV之间的桥梁它使得Kubernetes能够根据PVC的要求动态地创建和管理PV。
#编辑yaml配置文件
vim nfs-storageclass.yaml
apiVersion: storage.k8s.io/v1
#指定了Kubernetes API的版本和组
kind: StorageClass
#创建StorageClass资源
metadata:name: nfs-client-storageclass#指定名称
provisioner: nfs-storage
#指定了用于供应存储卷的供应器provisioner的名称
#与创建nfs-client-provisioner的PROVISIONER_NAME变量的值相同
parameters:
#供应器需要的任何额外参数archiveOnDelete: false#false表示在删除PVC时不会对数据进行存档即删除数据------------------------------------------------------------------------------------------------------
PROVISIONER这是负责为PersistentVolumeClaimsPVCs动态创建PersistentVolumesPVs的存储系统RECLAIMPOLICY定义了当PersistentVolumePV的声明PVC被删除时PV应该怎么做。Delete策略意味着PV和它上面的数据将被删除。VOLUMEBINDINGMODE定义了如何以及何时将PersistentVolumeClaimsPVCs绑定到PersistentVolumesPVs。Immediate模式意味着一旦PVC被创建就会立即查找并绑定一个合适的PV。ALLOWVOLUMEEXPANSION定义了是否允许扩展已存在的PersistentVolumePV。设置为false表示不允许扩展。
-----------------------------------------------------------------------------------------------------kubectl apply -f nfs-storageclass.yaml
#创建资源kubectl get storageclass
#查看资源信息7、创建PVC
7.1 关闭自链接
在创建PVC之前首先需要修改以下APIserver的参数
vim /etc/kubernetes/manifests/kube-apiserver.yaml
.......
spec:containers:- command:- kube-apiserver- --feature-gatesRemoveSelfLinkfalse#添加此字段用于关闭自链接self-link功能在Kubernetes 1.20及更高版本中由于API的更改许多组件不再使用或提供自链接字段。当NFS Provisioner尝试访问PVCPersistent Volume Claim的自链接以创建PV时可能会因为找不到该字段而报错。报错示例报错信息可能类似于“unexpected error getting claim reference: selfLink was empty, cant make reference”。
#这表明Provisioner试图获取PVC的自链接但发现它是空的kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml
#更新apiserverkubectl get pod -n kube-system |grep apiserver
#查看创建的apiserver信息kubectl delete pod kube-apiserver -n kube-system
#删除之前的kube-apiserverkubectl get pod -n kube-system |grep apiserver
#查看apiserver信息7.2 创建PVC
#编辑yaml配置文件
vim pvc-pod.yaml
apiVersion: v1
kind: PersistentVolumeClaim
#定义持久卷声明PersistentVolumeClaim用于请求持久卷
metadata:name: test-nfs-pvc#持久卷声明的名称
spec:accessModes:- ReadWriteMany#访问模式设置为读写多个节点storageClassName: nfs-client-storageclass#关联的存储类对象resources:requests:storage: 1Gi#请求的存储容量为1Gi
---
#定义Pod用于使用持久卷
apiVersion: v1
kind: Pod
metadata:name: test-storageclass-pod#Pod 的名称
spec:containers:- name: busyboximage: busybox:latestimagePullPolicy: IfNotPresentcommand:- /bin/sh- -cargs:- sleep 3600#命令参数让容器保持运行状态volumeMounts:- name: nfs-pvc#指定挂载的持久卷名称mountPath: /mnt#挂载路径restartPolicy: Never#Pod 的重启策略volumes:- name: nfs-pvc#定义一个名为nfs-pvc的卷persistentVolumeClaim:claimName: test-nfs-pvc#引用之前定义的持久卷声明的名称#这个 YAML 文件定义了一个 Kubernetes Pod 和一个 PersistentVolumeClaim持久卷声明。Pod 使用了名为 test-nfs-pvc 的持久卷声明请求了 1Gi 的存储空间并使用了 nfs-client-storageclass 存储类。Pod 中的容器使用了 BusyBox 镜像并将持久卷挂载到 /mnt 路径下。 Pod 的重启策略设置为 Never这意味着当 Pod 退出时不会自动重启。kubectl apply -f pvc-pod.yaml
#创建资源nfs服务器节点
ls /nfs/k8s/
#创建完pvc后会在NFS服务器的共享目录中建立一个文件
#自动创建的PV会以${namespace}-${pvcName}-${pvName}的目录格式放到NFS服务器上8、验证
master节点
kubectl exec -it test-storageclass-pod sh
#进入容器内部cd mnt
#切换到挂载目录echo this is xxxx index.html
#编辑访问页面exit
#退出NFS服务器节点
cd /nfs/k8s/
cd default-test-nfs-pvc-pvc-93d17ec0-127e-4e6d-b230-2844605abf27/
#切换目录cat index.html
#查看页面内容总结
Volume
emptyDir可以实现Pod中的容器之间共享数据但是存储卷不能持久化数据且会随着Pod生命周期结束而一起删除hostpath可以实现持久化存储使用node节点的目录或文件挂载到容器但是存储空间会收到node节点单机限制node节点故障数据会丢失Pod会跨节点不能共享数据NFS可以实现持久化存储使用NFS将存储设备空间挂载到容器中Pod可以跨Node节点共享数据
PV和PVC
PV 持久卷Persistent Volumes是集群中的一块存储资源由管理员事先创建或由动态供应机制如StorageClass自动创建。Kubernetes指定的存储设备空间中创建可持久化的存储的资源。PVC持久卷声明Persistent Volume Claims是用户对存储的请求或声明是对PV存储资源请求和绑定 Pod通过挂载PVC来使用PV。这种方式提供了存储的抽象和解耦使得应用无需关心具体的存储细节。当Pod销毁或重建时与之关联的PVC仍然保留保证了数据的持久性。
PV 定义 PV是Kubernetes集群中的一块网络存储它独立于Pod存在并由管理员创建和配置。PV可以是各种存储系统如NFS、iSCSI、云提供商的存储、本地存储等。PV定义了存储的容量、访问模式ReadWriteOnce、ReadOnlyMany、ReadWriteMany、存储类别等属性。 生命周期 PV的生命周期是独立于Pod的即使Pod被删除PV仍然存在可以被其他Pod继续使用。PV的状态包括可用Available、绑定Bound、释放Released、回收Retained等状态。 作用 PV具体对存储进行配置和分配pod等资源可以使用PV抽象出来的存储资源。PV提供了各种存储资源如NFS、iSCSI等为PVC提供实际存储的载体。
PVC 定义 PVC是用户对存储资源的请求它定义了Pod对存储的需求。在创建Pod时可以通过PVC来请求存储资源。PVC可以指定所需的存储容量、访问模式等参数但通常不需要指定具体的PV。 与PV的关系 PVC与PV之间是一种声明与提供的关系。PVC声明了对存储资源的需求而PV则是提供这些资源的实际载体。当PVC被创建时Kubernetes会尝试将其与满足其要求的PV进行绑定。匹配的过程是根据PVC的标签选择器和PV的标签进行匹配只有匹配成功的PV才能被绑定到PVC。 生命周期 PVC在绑定PV时如果匹配到合适的PV就与该PV进行绑定Pod应用可以使用该PVC作为存储。如果匹配不到合适的PVPVC将处于Pending状态直到有合适的PV可用为止。 作用 PVC使得Pod与具体的存储实现解耦提高了可移植性。通过PVC开发人员不需要关心存储资源的实际位置和类型只需要定义好存储需求即可。
静态PV的使用
准备存储设备和共享目录创建PV资源配置存储类型、访问模式、存储的能力大小创建PVC资源并且配置请求PV资源的访问模式和存储大小绑定PVPVC和PV是一对一的绑定关系PV访问模式中必须支持PVC请求访问模式请求的存储空间优先选择相等存储大小的PV资源如果没有会选择大于请求的存储大小的PV资源创建Pod资源 存储类设置PersistenVolumeClaim 在容器配置存储挂载
StorageClass——动态存储 存储类定义了存储的“类”用于动态供应PV。管理员可以根据不同的需求如性能、成本定义多个存储类。 用户在创建PVC时可以选择一个存储类Kubernetes会自动匹配并创建合适的PV。 对于存储资源虽然不像CPU和内存那样频繁地设置请求和限制但在使用PV/PVC时可以通过设置存储容量的大小来间接限制使用量。 在Pod的YAML定义中可以通过volumeMounts来指定容器如何挂载卷以及是否需要设置读写权限等。 Pod中的存储卷可以配置访问模式如只读、读写来确保数据的安全性。 对于敏感数据推荐使用Secrets或ConfigMaps并注意权限控制。
动态创建PV的过程
准备NFS共享服务器和共享目录创建sa服务账号进行RBAC角色资源操作权限的授权创建NFS-Client-Provisioner 存储插件以Pod形式运行的配置中关联sa服务账号使我们存储插件获得相关资源的权限操作权限创建StorageClass资源配置中光存储插件的名称配置创建PVC资源配置中关联StorageClass的资源的名称此时会在NFS服务器上生成相关的PV的共享目录目录名 n a m e s p a c e {namespace} namespace{PVCname}${PVname}格式命名创建Pod资源存储类型设置成PersistentVolumeClain在容器中配置存储挂载即可
