网站公司做文员,行业网站 源码,做pc端网站用什么框架,织梦网站采集侠怎么做目录
引言
一、存储卷
#xff08;一#xff09;存储卷定义
#xff08;二#xff09;存储卷的作用
1.数据持久化
2.数据共享
3.解耦
4.灵活性
#xff08;三#xff09;存储卷的分类
1.emptyDir存储卷
1.1 定义
1.2 特点
1.3 示例
2.hostPath存储卷
2.1 …目录
引言
一、存储卷
一存储卷定义
二存储卷的作用
1.数据持久化
2.数据共享
3.解耦
4.灵活性
三存储卷的分类
1.emptyDir存储卷
1.1 定义
1.2 特点
1.3 示例
2.hostPath存储卷
2.1 定义
2.2 特点
2.3 示例
3.nfs存储卷
3.1 定义
3.2 特点
3.3 示例
二、PV与PVC
一PV与PVC的定义
1.PV
2.PVC
二PV与PVC的关系
三实现过程
四静态PV
1.建立共享目录
2.定义PV
2.1 查看定义字段
2.3 创建PV
3.定义PVC
3.1 查看定义字段
3.2 创建PVC
4.创建pod
五动态PV
1.动态pv的定义
1.1 StorageClass
1.2 Provisioner
1.3 NFS-CLIENT-PROVISIONER
2.动态PV的作用
3.动态PV的使用流程
4.实现动态PV
4.1 创建共享目录
4.2 部署NFS-CLIENT-PROVISIONER
4.3 创建Service Account
4.4 创建集群角色并绑定
4.4.1 创建clusterole
4.4.2 集群角色绑定
4.5 创建NFS Provisioner
4.5.1 基本介绍
4.5.2 创建
4.6 创建StorageClass
4.7 创建PVC
4.7.1 关闭自链接
4.7.2 创建PVC
4.8 创建Pod
总结 引言
在KubernetesK8s中持久化存储是一个至关重要的概念它确保了在Pod重启或迁移时数据不会丢失。为了实现这一目标Kubernetes引入了PersistentVolumePV和PersistentVolumeClaimPVC这两个资源对象。本文将详细介绍PV和PVC的概念、工作原理以及它们之间的交互方式。
一、存储卷
在介绍PV与PVC之前首先了解一下什么是存储卷
一存储卷定义
存储卷是Kubernetes中的一个重要概念它为容器提供了持久化存储或其他类型的存储的能力。Pod中的容器可以通过存储卷来访问文件系统存储数据。存储卷的类型有很多如emptyDir、hostPath、NFS等。这些存储卷类型都有其特定的用途和限制
二存储卷的作用
1.数据持久化
当Pod中的容器因为各种原因如升级、故障等被销毁或重启时存储在容器内的数据通常会丢失。通过使用存储卷可以将数据存储在Pod生命周期之外的位置确保数据即使在容器或Pod重启后仍然可用。
2.数据共享
存储卷允许多个容器在Pod内部共享数据。这对于需要共享配置、日志或其他数据的容器来说非常有用。通过挂载相同的存储卷不同的容器可以访问并修改其中的数据。
3.解耦
通过将数据存储在存储卷中而不是直接存储在容器内部可以实现应用与数据之间的解耦。这意味着应用的代码和数据可以分开管理从而简化应用的部署、升级和备份过程。
4.灵活性
Kubernetes支持多种类型的存储卷包括emptyDir、hostPath、NFS等。这为用户提供了很大的灵活性可以根据应用的需求选择最适合的存储解决方案。
还有一些其它的特性如
安全性通过使用只读存储卷可以限制容器对数据的修改权限从而提高数据的安全性。此外一些存储卷类型如加密云存储还可以提供额外的数据保护功能。
可移植性存储卷的使用使得应用在不同Kubernetes集群之间的迁移变得更加容易。只要目标集群支持相同的存储卷类型并且已经配置了相应的存储资源就可以轻松地将应用及其数据迁移到新的环境中。
日志和监控存储卷可以用于存储应用的日志和监控数据。通过将日志和监控数据写入存储卷中可以长期保存这些数据并使用专门的日志和监控工具进行分析和警报。
三存储卷的分类
1.emptyDir存储卷
1.1 定义
emptyDir是Kubernetes中一种最简单的存储卷类型其生命周期与Pod相同。当Pod被分配给某个节点时会为该Pod创建一个emptyDir卷并且只要Pod在该节点上运行卷就一直存在。一旦Pod被删除emptyDir卷中的数据也会被永久删除
1.2 特点
生命周期emptyDir的生命周期与Pod相同即当Pod被删除时emptyDir也会被删除。
用途emptyDir常用于临时数据如缓存空间、基于磁盘的归并排序等。实现容器与容器之间数据共享
存储位置emptyDir存储卷位于Pod所在节点的本地文件系统中
1.3 示例
在yaml文件中定义emptyDir存储卷属性
[rootmaster01 data]#vim pod.yaml
[rootmaster01 data]#cat pod.yaml
apiVersion: v1 #指定Kubernetes API 的版本
kind: Pod #指定创建的资源类型为Pod
metadata: #定义pod元信息name: pod-nginx #指定pod的名称
spec: #定义Pod的期望状态。containers: #定义Pod中要运行的容器- name: nginx #指定容器名称为nginximage: nginx:1.18.0 #指定镜像imagePullPolicy: IfNotPresent #指定镜像拉取策略优先使用本地镜像本地没有则会拉取镜像ports: #定义端口列表- name: http #指定端口名称为httpcontainerPort: 80 #指定容器暴漏端口为80volumeMounts: #定义容器要挂载的卷- name: web #这是卷的名称与下面的volumes部分中定义的卷名称相对应mountPath: /usr/shart/nginx/html #容器内部的挂载路径应该是- name: centos #指定容器名称centosimage: centos:7 #指定镜像imagePullPolicy: IfNotPresent #指定镜像拉取策略volumeMounts: #定义容器要挂载的卷- name: web #同样定义卷的名称与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中的容器之间共享数据注释上述yaml文件的最终效果为
最下方volumes定义了一个名为web的卷类型为emptyDir。emptyDir是一个临时卷它的生命周期与Pod相同。当Pod被分配给节点时会创建一个空的卷emptyDir: {}并且只要Pod运行在该节点上卷就一直存在。如果Pod从节点上删除无论是由于某些错误还是正常的删除操作则卷中的数据也会被永久删除。
nginx容器将web卷emptyDir: {}挂载到/usr/share/nginx/html路径下。
centos容器将web卷emptyDir: {}挂载到/data/路径下。
因此当这个Pod被创建并运行后两个容器都可以访问和修改web卷emptyDir: {}中的数据。这可以用于共享数据、配置文件、日志文件等。但是由于emptyDir是临时的所以一旦Pod被删除这些数据也会丢失
[rootmaster01 data]#kubectl apply -f pod.yaml
pod/pod-nginx created
[rootmaster01 data]#kubectl get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nginx 2/2 Running 0 5s 10.244.1.180 node01 none none
[rootmaster01 data]#curl 10.244.1.180
2024-05-28--13:20:55
2024-05-28--13:20:57
2024-05-28--13:20:59
2024-05-28--13:21:01
2024-05-28--13:21:03
......
进入centos容器查看挂载情况 删除pod数据也就会随之消失使用副本控制器创建的pod也只会重新创建新的pod数据并不会移交同步
2.hostPath存储卷
2.1 定义
hostPath卷将主机节点文件系统中的文件或目录挂载到Pod中。这使得容器可以访问到宿主机上的文件或目录从而实现数据的持久化存储。
2.2 特点
生命周期hostPath卷的生命周期与节点一致而不是与Pod一致。即使Pod被删除hostPath卷中的数据仍会保留在节点上。
用途hostPath卷通常用于一些需要访问宿主机文件系统的特殊场景如运行一些需要访问宿主机文件的守护进程。
限制由于hostPath卷直接挂载到宿主机的文件系统上因此它可能会受到宿主机文件系统的限制例如磁盘空间、权限等
2.3 示例
[rootmaster01 data]#kubectl delete pod --all #删除所有容器
[rootmaster01 data]#vim pod-hostpath.yaml
[rootmaster01 data]#cat pod-hostpath.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-hostpath
spec:containers:- name: nginximage: nginx:1.18.0imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80volumeMounts: #定义如何在容器内部挂载存储卷- name: web #指定要挂载的存储卷的名称volumes.name字段定义的名称mountPath: /usr/share/nginx/html #容器内部的目录路径存储卷将被挂载到这个路径上readOnly: false #false表示容器可以读写该存储卷volumes: #定义宿主机上的目录文件为Pod中可用的存储卷- name: web #自定义存储卷的名称hostPath: #指定存储卷类型为hostPathpath: /data/web/nginx/ #指定宿主机上可以挂载到pod中的目录或文件type: DirectoryOrCreate #指定hostPath的类型DirectoryOrCreate表示不存时创建
--------------------------------------------------------------------------------------
readOnly
#如果设置为true则容器以只读方式挂载的存储卷如果设置为false或空值则容器可以读写该存储卷hostPath
#允许将主机上的文件系统目录或文件挂载到Pod中type 可设置的类型值
# (默认)不进行任何特殊处理。
#DirectoryOrCreate如果指定路径下的目录不存在则创建它。
#Directory目录必须存在。
#FileOrCreate如果指定路径下的文件不存在则创建它。
#File文件必须存在。
#SocketUNIX套接字必须存在。
#CharDevice字符设备必须存在。
#BlockDevice块设备必须存在 此pod在node02节点上创建在node02节点查看文件
[rootnode02 ~]#cd /data/web/nginx/
[rootnode02 nginx]#ls
[rootnode02 nginx]#echo this is hostpath index.html
#创建访问页面因为是将宿主机上的目录挂载到pod上会覆盖挂载点(/usr/share/nginx/html)下的文件
[rootnode02 nginx]#curl 10.244.2.195
this is hostpath即使删除pod由于文件是在宿主机上hostPath存储卷模式下不会删除节点上的文件
[rootmaster01 data]#kubectl delete pod pod-hostpath
pod pod-hostpath deleted-----------------------------------------------------------------------------
//node02节点查看
[rootnode02 nginx]#ls
index.html
[rootnode02 nginx]#cat index.html
this is hostpath需要注意的是当宿主机即node节点发生故障时数据仍会丢失且hostPath卷直接引用主机上的文件或目录因此它可能会暴露敏感数据或允许Pod执行不受限制的操作。在生产环境中通常建议使用更安全的存储解决方案如持久卷PersistentVolumes或云提供商提供的存储服务。
当pod生命周期结束后创建新的pod只要是指定挂载此存储卷依然可以访问到数据 hostPath会自动优先选择合适的节点如node02上有指定的挂载路径则不需要再去node01节点上创建会自动选择带有指定挂载路径的节点
3.nfs存储卷
3.1 定义
NFSNetwork File System是一种基于TCP/IP传输的网络文件系统协议。通过使用NFS协议客户机可以像访问本地目录一样访问远程服务器中的共享资源。在Kubernetes中NFS存储卷允许Pod访问NFS服务器上的共享目录。
3.2 特点
网络存储NFS存储卷是一种网络存储解决方案可以实现数据的跨节点共享和访问。
持久性NFS存储卷的数据存储在NFS服务器上因此具有持久性。即使Pod被删除或重新调度到其他节点数据仍然保留在NFS服务器上。
多个客户端访问NFS支持多个客户端同时挂载和访问同一个NFS服务器上的共享目录。
配置和管理NFS需要单独配置和管理NFS服务器包括安装NFS软件包、设置共享目录、配置访问权限等
3.3 示例
[rootmaster01 data]#kubectl delete pod --all #删除所有容器
首先搭建NFS共享服务器并指定共享目录
//在nfs服务器上操作
[rootnfs ~]#mkdir -p /nfs/volumes
[rootnfs ~]#chmod -R 777 /nfs/volumes/
[rootnfs ~]#echo this is nfs /nfs/volumes/index.html
#创建共享目录并添加权限自定义访问界面[rootnfs ~]#vim /etc/exports
[rootnfs ~]#cat /etc/exports
/nfs/volumes/ 192.168.83.0/24(rw,no_root_squash)
#添加共享目录信息及权限到/etc/exports文件中进行共享[rootnfs ~]#systemctl start rpcbind
[rootnfs ~]#systemctl start nfs
#启动共享服务
[rootnfs ~]#ss -natp |grep rpcbind #RPC端口远程连接
LISTEN 0 128 *:111 *:* users:((rpcbind,pid46682,fd4),(systemd,pid1,fd34))
LISTEN 0 128 :::111 :::* users:((rpcbind,pid46682,fd11))
[rootnfs ~]#ss -natp |grep 2049 #NFS端口提供服务
LISTEN 0 64 *:2049 *:*
LISTEN 0 64 :::2049 :::*//任意节点查看共享情况
[rootnode01 ~]#showmount -e 192.168.83.60
Export list for 192.168.83.60:
/nfs/volumes/ 192.168.83.0/24
定义nfs存储卷文件
[rootmaster01 data]#vim pod-nfs.yaml
[rootmaster01 data]#cat pod-nfs.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-nfs
spec:containers:- name: nginximage: nginx:1.18.0imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80volumeMounts:- name: nfsvmountPath: /usr/share/nginx/htmlreadOnly: falsevolumes:- name: nfsvnfs: #指定使用nfs存储卷path: /nfs/volumes #指定nfs服务器的共享目录server: 192.168.83.60 #指定挂载的nfs服务器地址映射后也可以写主机名
创建pod后访问容器就可以访问到自定义的web界面
[rootmaster01 data]#kubectl apply -f pod-nfs.yaml
pod/pod-nfs created
[rootmaster01 data]#kubectl get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nfs 1/1 Running 0 4s 10.244.1.181 node01 none none
[rootmaster01 data]#curl 10.244.1.181
this is nfs
同样的删除pod后重新创建只要使用nfs挂载此文件可以得到数据的持久化存储。
但是容易发生单点故障服务器宕机时所有客户端无法访问多台客户端挂载在同一台服务器上管理维护较繁琐
总结来说emptyDir、hostPath和NFS是Kubernetes中三种不同的存储卷类型它们各自具有不同的特点和用途。
emptyDir适用于临时数据和需要共享数据的Pod
hostPath适用于需要访问宿主机文件系统的特殊场景
NFS则是一种网络存储解决方案可以实现数据的跨节点共享和访问
二、PV与PVC
在Kubernetes中存储卷Volumes是Pod中可以访问的存储的抽象用于存储数据。然而随着Kubernetes集群的复杂性和多租户的需求增长仅仅依赖Pod中的存储卷定义已经不足以满足所有存储需求。为了解决这个问题Kubernetes引入了PersistentVolumePV和PersistentVolumeClaimPVC的概念它们为存储资源提供了更高层次的管理和抽象
一PV与PVC的定义
1.PV
定义PVPersistent Volume是对底层的共享存储的一种抽象它由管理员进行创建和配置。PV是与具体的底层共享存储技术的实现方式相关的例如Ceph、GlusterFS、NFS等它们通过插件机制完成与共享存储的对接实现数据持久化存储。
关键信息PV作为对存储资源的定义主要涉及存储能力即存储空间的大小、访问模式如ReadWriteOnce、ReadOnlyMany、ReadWriteMany等、存储类型、回收策略以及后端存储类型等关键信息的设置。
2.PVC
定义PVCPersistent Volume Claim是用户对存储的一种声明它与Pod比较类似。Pod消耗的是节点资源而PVC消耗的是PV资源。PVC可以请求特定的存储空间和访问模式而不需要用户关心底层的存储实现细节。
关键信息PVC主要涉及存储空间请求、访问模式、PV选择条件和存储类别等信息的设置。当PVC被创建时Kubernetes会尝试将其与满足其要求的PV进行绑定。如果系统中存在一个DefaultStorageClass那么在创建PVC的时候可以不指定storageClassName系统会自动使用默认的存储类型。
二PV与PVC的关系
在 Pod 中定义一个存储卷该存储卷类型为 PVC定义的时候直接指定大小PVC 必须与对应的 PV 建立关系PVC 会根据配置的定义去 PV 申请而 PV 是由存储空间创建出来的。PV 和 PVC 是 Kubernetes 抽象出来的一种存储资源
简单来说类似于LVM逻辑卷LVM逻辑卷是将磁盘整合建立卷组而后根据卷组建立逻辑卷并指定使用空间的大小
而PV就是将共享服务器例如NFS、CEPH等进行划分建立一个或多个PV存储卷PVC指定挂载存储卷的大小及访问模式读、写挂载对应的PV卷达到数据持久化存储
一般来说PV和PVC之间的相互作用需要遵循以下生命周期 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之间建立联系请求的存储空间优先选择相等的存储大小的PV资源如果没有会选择大于请求资源的PV资源但是使用大小还是PVC请求的资源大小会造成一定的资源浪费
④创建pod指定需要使用的PVC
四静态PV
静态PV就是手动创建PV然后等待PVC请求建立连接
NFS使用PV与PVC
1.建立共享目录
NFS服务器上建立共享目录共享目录
//nfs服务器上操作创建共享目录
[rootnfs ~]#mkdir -p /nfs/pv/pv{1..4}
[rootnfs ~]#ls /nfs/pv/
pv1 pv2 pv3 pv4
[rootnfs ~]#chmod -R 777 /nfs/pv///添加共享目录
[rootnfs ~]#cat /etc/exports
/nfs/pv/pv1 192.168.83.0/24(rw,no_root_squash)
/nfs/pv/pv2 192.168.83.0/24(rw,no_root_squash)
/nfs/pv/pv3 192.168.83.0/24(rw,no_root_squash)
/nfs/pv/pv4 192.168.83.0/24(rw,no_root_squash)
[rootnfs ~]#exportfs -r
[rootnfs ~]#showmount -e
Export list for nfs:
/nfs/pv/pv4 192.168.83.0/24
/nfs/pv/pv3 192.168.83.0/24
/nfs/pv/pv2 192.168.83.0/24
/nfs/pv/pv1 192.168.83.0/24
2.定义PV
2.1 查看定义字段
使用kubectl explain查看pv的定义方式
[rootmaster01 data]#kubectl explain pv
KIND: PersistentVolume
VERSION: v1apiVersion string #设置为v1即可通用版本kind string #设置PV卷kind的值为PersistentVolumemetadata Object #PV是集群级别的资源可以跨namespace所以不需要指定spec Object #定义PV的特性status Object #状态创建后自动生成一般不需要配置查看pv.spec可设置字段
[rootmaster01 data]#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
定义3个PV分别定义挂载的路径以及访问模式还有PV划分的大小。
[rootmaster01 data]#vim pv.yaml
[rootmaster01 data]#cat pv.yaml
apiVersion: v1
kind: PersistentVolume #定义了资源的类型为PersistentVolume
metadata:name: pv01labels:name: pv01
spec: #这是PV的规格描述nfs: #指定了PV的后端存储类型为NFSpath: /nfs/pv/pv1 #NFS服务器上存储卷的路径server: 192.168.83.60 #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: /nfs/pv/pv2server: 192.168.83.60accessModes: [ReadWriteOnce] #定义PV的访问模式为RWOcapacity:storage: 2Gi #指定PV存储容量为2GiB
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv03labels:name: pv03
spec:nfs:path: /nfs/pv/pv3server: 192.168.83.60accessModes: [ReadWriteMany,ReadWriteOnce] #定义PV的访问模式为两种RWX,RWOcapacity:storage: 2Gi #指定PV存储容量为2GiB
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv04labels:name: pv04
spec:nfs:path: /nfs/pv/pv4server: 192.168.83.60accessModes: [ReadWriteMany,ReadWriteOnce] #定义PV的访问模式为两种RWX,RWOcapacity:storage: 3Gi #指定PV存储容量为3GiB
查看创建结果
[rootmaster01 data]#kubectl apply -f pv.yaml
persistentvolume/pv01 created
persistentvolume/pv02 created
persistentvolume/pv03 created
persistentvolume/pv04 created
[rootmaster01 data]#kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv01 1Gi RWO,RWX Retain Available 6s
pv02 2Gi RWO Retain Available 6s
pv03 2Gi RWO,RWX Retain Available 6s
pv04 3Gi RWO,RWX Retain Available 6s可用大小 访问模式 3.定义PVC
3.1 查看定义字段
[rootmaster01 data]#kubectl explain pvc
......apiVersion: v1
kind: PersistentVolumeClaim
metadata
spec
status
.....#apiVersion、metadata、status字段与pv基本一致kind字段设置为PersistentVolumeClaim
查看pvc.spec下的字段
[rootmaster01 data]#kubectl explain 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信息匹配
[rootmaster01 data]#vim pvc.yaml
[rootmaster01 data]#cat pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim #指定资源类型为PersistentVolumeClaim即PVC
metadata:name: pvc01
spec:accessModes: [ReadWriteMany] #定义期望获得的访问模式为ReadWriteMany,即RWXresources: #描述 PVC 的资源需求requests: #列出PVC所请求的特定资源storage: 2Gi #指定PVC所请求的存储容量。指定为2Gi那么就会匹配存储容量为2Gi的PV
查看创建结果 PV 的状态STATUS有以下 4 种 ● Available可用表示可用状态还未被任何 PVC 绑定 ● Bound已绑定表示 PV 已经绑定到 PVC ● Released已释放表示 PVC 被删掉但是资源尚未被集群回收 ● Failed失败表示该 PV 的自动回收失败
4.创建pod
定义创建pod的yaml文件并定义pvc挂载存储
[rootmaster01 data]#vim pod-pv.yaml
[rootmaster01 data]#cat pod-pv.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-pvnamespace: default
spec:containers:- name: nginximage: nginx:1.18.0volumeMounts:- name: web #指定要挂载的存储卷名称与volumes.name字段设置的一致mountPath: /usr/share/nginx/html #将volumes字段设置的存储卷挂载到该路径下volumes:- name: web #定义存储卷名称persistentVolumeClaim: #定义存储卷是由PersistentVolumeClaim(PVC)提供claimName: pvc01 #指定PVC名称的pvc01
创建pod
[rootmaster01 data]#kubectl apply -f pod-pv.yaml
pod/pod-pv created
[rootmaster01 data]#kubectl get pod pod-pv -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-pv 1/1 Running 0 13s 10.244.2.199 node02 none none在nfs服务器上创建访问页面
//NFS服务器操作
[rootnfs ~]#cd /nfs/pv/pv3 #PVC绑定的路径
[rootnfs pv3]#echo this is pv3 index.html访问pod就可以看到自定义的访问界面
[rootmaster01 data]#curl 10.244.2.199
this is pv3
此时就可以实现存储数据的持久化哪怕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
创建之前清空之前的操作记录
[rootmaster01 data]#kubectl delete pod --all
pod pod-pv deleted
[rootmaster01 data]#kubectl delete pvc --all
persistentvolumeclaim pvc01 deleted
[rootmaster01 data]#kubectl delete pv --all
persistentvolume pv01 deleted
persistentvolume pv02 deleted
persistentvolume pv03 deleted
persistentvolume pv04 deleted
---------------------------------------------------------------------
#删除时需要注意的是首先删除PVC因为PV一旦被占用则无法进行删除需要删除PVC释放PV资源
4.1 创建共享目录
//NFS服务器操作
[rootnfs pv3]#mkdir /nfs/k8s
[rootnfs pv3]#chmod -R 777 /nfs/k8s/
[rootnfs pv3]#vim /etc/exports
[rootnfs pv3]#cat /etc/exports
/nfs/k8s 192.168.83.0/24(rw,no_root_squash,sync)
[rootnfs pv3]#exportfs -r #刷新配置
[rootnfs pv3]#showmount -e #验证共享目录是否共享成功
Export list for nfs:
/nfs/k8s 192.168.83.0/244.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
[rootnode01 opt]#ls nfs-client-provisioner.tar
nfs-client-provisioner.tar
[rootnode01 opt]#docker load -i nfs-client-provisioner.tar
8dfad2055603: Loading layer [] 4.284MB/4.284MB
a17ae64bae4f: Loading layer [] 2.066MB/2.066MB
bd01fa00617b: Loading layer [] 39.72MB/39.72MB
Loaded image: quay.io/external_storage/nfs-client-provisioner:latest//node02
[rootnode02 opt]#ls nfs-client-provisioner.tar
nfs-client-provisioner.tar
[rootnode01 opt]#docker load -i nfs-client-provisioner.tar
8dfad2055603: Loading layer [] 4.284MB/4.284MB
a17ae64bae4f: Loading layer [] 2.066MB/2.066MB
bd01fa00617b: Loading layer [] 39.72MB/39.72MB
Loaded image: quay.io/external_storage/nfs-client-provisioner:latest或者使用registry.cn-hangzhou.aliyuncs.com/jijic/provisioner镜像也可以实现NFS共享
上述镜像存在弃用的风险可以使用registry.cn-hangzhou.aliyuncs.com/jijic/provisioner:v4.0.2 这个镜像它是针对 NFS 客户端预置配置的国内镜像地址。
在node节点上使用docker命令下载
[rootnode01 ~]#docker pull registry.cn-hangzhou.aliyuncs.com/jijic/provisioner:v4.0.2
4.3 创建Service Account
ServiceAccount是Kubernetes中的一种特殊类型的用户账户用于为Pod中的进程提供身份验证和权限控制。为NFS-CLIENT-PROVISIONER创建一个ServiceAccount可以确保它具有在集群中执行其职责所需的必要权限
[rootmaster01 pv]#vim service-account.yaml
[rootmaster01 pv]#cat service-account.yaml
apiVersion: v1
kind: ServiceAccount #指定资源类型为用户
metadata:name: nfs-client #指定用户名称
[rootmaster01 pv]#kubectl apply -f service-account.yaml
serviceaccount/nfs-client created
[rootmaster01 pv]#kubectl get sa #查看用户
NAME SECRETS AGE
default 1 13d
nfs-client 1 13s
4.4 创建集群角色并绑定
ClusterRole定义了集群级别的权限集而ClusterRoleBinding则将这些权限集绑定到特定的ServiceAccount或用户。为NFS-CLIENT-PROVISIONER创建一个ClusterRole并为其分配必要的权限如监听apiserver、获取集群资源列表、创建和删除PV等然后通过ClusterRoleBinding将其绑定到之前创建的ServiceAccount上。
[rootmaster01 pv]#kubectl explain clusterrole
#查看定义字段
4.4.1 创建clusterole
创建ClusterRole并添加相应的权限
[rootmaster01 pv]#vim cluster.yaml
[rootmaster01 pv]#cat cluster.yaml
apiVersion: rbac.authorization.k8s.io/v1 #这表示使用的是RBAC API的版本1
kind: ClusterRole #定义一个集群级别的角色
metadata: name: clusterrole-nfs #ClusterRole的名称用于在Kubernetes集群中唯一标识
rules: #ClusterRole中定义的具体权限列表- apiGroups: []resources: [persistentvolumes]verbs: [get, list, watch, create, delete]
#第一个规则组
#apiGroups: []表示核心API组不包含任何前缀的API组
#resources: [persistentvolumes]表示对持久卷PersistentVolumes的权限。
#verbs: 列出了可以执行的操作get(获取)、list(列表)、watch(监听)、create(创建)和delete(删除)- apiGroups: []resources: [persistentvolumeclaims]verbs: [get, list, watch, update]
#第二各规则组与第一个规则类似但针对的是持久卷声明PersistentVolumeClaims- apiGroups: [storage.k8s.io]resources: [storageclasses]verbs: [get, list, watch]
#第三个规则组
#apiGroups: [storage.k8s.io]这是存储API组的名称
#resources: [storageclasses]表示对存储类StorageClasses的权限。
#verbs: 列出了可以执行的操作但仅允许读取操作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的广泛权限包括创建、删除、获取、列表、监听、补丁和更新[rootmaster01 pv]#kubectl apply -f cluster.yaml
clusterrole.rbac.authorization.k8s.io/clusterrole-nfs created
[rootmaster01 pv]#kubectl get clusterroles clusterrole-nfs -owide
NAME CREATED AT
clusterrole-nfs 2024-05-29T09:30:10Z
4.4.2 集群角色绑定
[rootmaster01 pv]#vim clusterbind.yaml
[rootmaster01 pv]#cat clusterbind.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding #资源类型为ClusterRoleBinding集群级别的角色绑定
metadata:name: nfs-client-clusterrolebinding #定义资源名称
subjects: #定义了哪些用户或用户组会被授予权限
- kind: ServiceAccount #引用一个ServiceAccountname: nfs-client #ServiceAccount名称为nfs-client这是之前创建的用户namespace: default #指定ServiceAccount所在命名空间
roleRef: #定义了该绑定所引用的ClusterRolekind: ClusterRole #正在引用一个ClusterRolename: clusterrole-nfs #ClusterRole的名称上一步创建的ClusterRole名称apiGroup: rbac.authorization.k8s.io #这是API组的名称对于ClusterRole它通常是rbac.authorization.k8s.io
[rootmaster01 pv]#kubectl apply -f clusterbind.yaml
clusterrolebinding.rbac.authorization.k8s.io/nfs-client-clusterrolebinding created
[rootmaster01 pv]#kubectl get clusterrolebindings nfs-client-clusterrolebinding -owide
NAME ROLE AGE USERS GROUPS SERVICEACCOUNTS
nfs-client-clusterrolebinding ClusterRole/clusterrole 69s default/nfs-client-nfs
4.5 创建NFS Provisioner
4.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持久卷
4.5.2 创建
使用Deployment创建nfs-client-provisioner防止因为它发生故障时退出导致NFS服务器无法使用
[rootmaster01 pv]#cat 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 #指定Pod使用的ServiceAccount的名称containers:- name: nfs-client-provisionerimage: quay.io/external_storage/nfs-client-provisioner:latest #之前下载的镜像
#该镜像如果不能使用该镜像可以在node节点上使用命令下载registry.cn-hangzhou.aliyuncs.com/jijic/provisioner镜像使用imagePullPolicy: IfNotPresentvolumeMounts: #定义容器内的挂载点挂载到什么位置- name: nfs-k8s #挂载卷名称。volumes定义的mountPath: /persistentvolumes #挂载到该路径env: #定义容器的环境变量。- name: PROVISIONER_NAME #变量名称配置provisioner的Namevalue: nfs-storage #变量值此值在建立StorageClass时使用- name: NFS_SERVER #变量名称指定NFS服务器value: 192.168.83.60 #NFS服务器地址或主机名- name: NFS_PATH #变量名称指定共享目录value: /nfs/k8s #NFS共享目录volumes: #定义Pod中的卷- name: nfs-k8s #卷的名称与上面的volumeMounts定义中的名称相匹配nfs: #定义NFS卷的参数server: 192.168.83.60 #NFS服务器的地址path: /nfs/k8s #NFS服务器上的共享路径-------------------------------------------------------------------------------
Recreate重建: 使用此策略时Kubernetes会首先终止所有的旧Pods然后等待这些Pods都被
完全删除并清理后再创建新的Pods。这意味着在更新过程中服务可能会经历一段不可用时间因
为所有的Pods都会被同时替换。虽然这种方法可能导致服务中断但它有时更简单、更可靠特别是
当应用程序不支持滚动更新或者需要确保在更新过程中没有两个版本的Pods同时运行时。
[rootmaster01 pv]#kubectl apply -f nfs-client-pro.yaml
deployment.apps/nfs-client-provisioner created
[rootmaster01 pv]#kubectl get deployments.apps nfs-client-provisioner
NAME READY UP-TO-DATE AVAILABLE AGE
nfs-client-provisioner 1/1 1 1 15s
[rootmaster01 pv]#kubectl get pod
NAME READY STATUS RESTARTS AGE
nfs-client-provisioner-544dbf9f94-f948s 1/1 Running 0 45s
4.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。
[rootmaster01 pv]#cat 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表示不允许扩展。 当以上过程完成后就实现了动态PV只需要创建PVC请求。动态PV会根据PVC请求自动创建对应的PVC资源并与PVC绑定。而后使用POD绑定PVC实现持久化存储
4.7 创建PVC
4.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的自链接但发现它是空的
[rootmaster01 data]#kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml
pod/kube-apiserver created
#更新apiserver
[rootmaster01 data]#kubectl get pod -n kube-system |grep apiserver
kube-apiserver 0/1 CrashLoopBackOff 1 19s
kube-apiserver-master01 1/1 Running 0 99s
[rootmaster01 data]#kubectl delete pod kube-apiserver -n kube-system
pod kube-apiserver deleted
#删除之前的kube-apiserver
4.7.2 创建PVC
[rootmaster01 pv]#vim pvc.yaml
[rootmaster01 pv]#cat pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: pvc-nfs
spec:accessModes: [ReadWriteMany]storageClassName: nfs-client-storageclass #指定关联StorageClass对象名称resources:requests:storage: 2Gi
PVC 通过 StorageClass 自动申请到空间 如果Provisioner没有创建PV那么它的日志中可能包含有关为什么无法创建PV的详细信息。使用kubectl logs nfs-provisioner-pod-name -n namespace来获取日志
创建完pvc后会在NFS服务器的共享目录中建立一个文件
[rootnfs nfs]#ls /nfs/k8s/
default-pvc-nfs-pvc-e2f92c4e-a04c-4243-a131-566c0103717e
#自动创建的PV会以${namespace}-${pvcName}-${pvName}的目录格式放到NFS服务器上
[rootmaster01 pv]#kubectl get pv,pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/pvc-e2f92c4e-a04c-4243-a131-566c0103717e 2Gi RWX Delete Bound default/pvc-nfs nfs-client-storageclass 20sNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/pvc-nfs Bound pvc-e2f92c4e-a04c-4243-a131-566c0103717e 2Gi RWX nfs-client-storageclass 20s4.8 创建Pod
[rootmaster01 pv]#vim pod.yaml
[rootmaster01 pv]#cat pod.yaml
apiVersion: v1
kind: Pod
metadata:name: nginx-pod
spec:containers:- name: nginximage: nginx:1.18.0volumeMounts:- name: nfs-pvcmountPath: /usr/share/nginx/htmlvolumes:- name: nfs-pvcpersistentVolumeClaim: #使用PersistentVolumeClaim作为卷源claimName: pvc-nfs #引用之前创建的PersistentVolumeClaim的名称
在NFS服务器的PV目录上自定义一个web访问界面 创建pod后访问的页面通过挂载就可以访问到PV的自定义web界面 总结
一PV
1.定义
PV是Kubernetes集群中的一块网络存储它独立于Pod存在并由管理员创建和配置。
PV可以是各种存储系统如NFS、iSCSI、云提供商的存储、本地存储等。
PV定义了存储的容量、访问模式ReadWriteOnce、ReadOnlyMany、ReadWriteMany、存储类别等属性。
2.生命周期
PV的生命周期是独立于Pod的即使Pod被删除PV仍然存在可以被其他Pod继续使用。
PV的状态包括可用Available、绑定Bound、释放Released、回收Retained等状态。
3.作用
PV具体对存储进行配置和分配pod等资源可以使用PV抽象出来的存储资源。
PV提供了各种存储资源如NFS、iSCSI等为PVC提供实际存储的载体。
二PVC
1.定义
PVC是用户对存储资源的请求它定义了Pod对存储的需求。
在创建Pod时可以通过PVC来请求存储资源。
PVC可以指定所需的存储容量、访问模式等参数但通常不需要指定具体的PV。
2.与PV的关系
PVC与PV之间是一种声明与提供的关系。
PVC声明了对存储资源的需求而PV则是提供这些资源的实际载体。
当PVC被创建时Kubernetes会尝试将其与满足其要求的PV进行绑定。
匹配的过程是根据PVC的标签选择器和PV的标签进行匹配只有匹配成功的PV才能被绑定到PVC。
3.生命周期
PVC在绑定PV时如果匹配到合适的PV就与该PV进行绑定Pod应用可以使用该PVC作为存储。
如果匹配不到合适的PVPVC将处于Pending状态直到有合适的PV可用为止。
4.作用
PVC使得Pod与具体的存储实现解耦提高了可移植性。
通过PVC开发人员不需要关心存储资源的实际位置和类型只需要定义好存储需求即可。
