PV/PVC
- 1、概念
- 1.1 基本定义
- 1.2 生命周期
- 1.3 PV 卷阶段状态
- 2、 示例
- 2.1 创建pod和PVC 与PV
- 2.2 绑定PV
- 2.3 强制删除pv,pvc
- 2.4 测试
1、概念
1.1 基本定义
- PersistentVolume(PV)是集群中由管理员配置的一段网络存储。 它是集群中的资源,就像节点是集群资源一样。 PV 是容量插件,如 Volumes,但其生命周期独立于使用 PV 的任 何单个 pod。 此 API 对象捕获存储实现的详细信息,包括 NFS,iSCSI 或特定于云提供程 序的存储系统。
- PersistentVolumeClaim(PVC)是由用户进行存储的请求。 它类似于 pod。 Pod 消耗节点 资源,PVC 消耗 PV 资源。Pod 可以请求特定级别的资源(CPU 和内存)。声明可以请求特 定的大小和访问模式(例如,可以一次读/写或多次只读)。
- 虽然 PersistentVolumeClaims 允许用户使用抽象存储资源,但是 PersistentVolumes 对于 不同的问题,用户通常需要具有不同属性(例如性能)。群集管理员需要能够提供各种 PersistentVolumes 不同的方式,而不仅仅是大小和访问模式,而不会让用户了解这些卷 的实现方式。对于这些需求,有 StorageClass 资源。
- 简单来说就是PV是用来做持久化存储的,对存储资源进行抽象,对外提供可以调用的地方。相当于是生产者。而PVC是用来实现调用功能的,相当于消费者。
1.2 生命周期
- PV 是群集中的资源。PVC 是对这些资源的请求,并且还充当对资源的检查。PV 和 PVC 之间 的相互作用遵循以下生命周期: Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling
- 供应准备 Provisioning—通过集群外的存储系统或者云平台来提供存储持久化支持。
- 静态提供 Static:集群管理员创建多个 PV。 它们携带可供集群用户使用的真实存储的详细信息。 它们存在于 Kubernetes API 中,可用于消费
- 动态提供 Dynamic:当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时,集群可能会尝试为 PVC 动态配置卷。 此配置基于 StorageClasses:PVC 必须请求一个 类,并且管理员必须已创建并配置该类才能进行动态配置。 要求该类的声明有效地为自己 禁用动态配置。
- 绑定 Binding—用户创建 pvc 并指定需要的资源和访问模式(也叫匹配模式)。在找到可用 pv 之前,pvc 会保持未绑定状态。
- 使用 Using—用户可在 pod 中像 volume 一样使用 pvc。
- 释放 Releasing—用户删除 pvc 来回收存储资源,pv 将变成“released”状态。由于还 保留着之前的数据,这些数据需要根据不同的策略来处理,否则这些存储资源无法被其他 pvc 使用。
- 回收 Recycling—pv 可以设置三种回收策略:保留(Retain),回收(Recycle)和删除 (Delete)。 - 保留策略:允许人工处理保留的数据。 - 删除策略:将删除 pv 和外部关联的存储资源,需要插件支持。 - 回收策略:将执行清除操作,之后可以被新的 pvc 使用,需要插件支持
1.3 PV 卷阶段状态
PV | 状态 |
---|
Bound | 卷已经被绑定到 claim 了 |
Available | 资源尚未被 claim 使用 |
Released | claim 被删除,卷处于释放状态,但未被集群回收 |
Failed | 卷自动回收失败 |
2、 示例
[root@master nfs-nfinx]
[root@master nfs-nfinx]
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 68d
nginx-dep1 NodePort 10.103.175.154 <none> 80:31077/TCP 7h9m
2.1 创建pod和PVC 与PV
[root@master pv-pvc]
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-dep1
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginxvolumeMounts:- name: wwwrootmountPath: /usr/share/nginx/htmlports:- containerPort: 80volumes:- name: wwwrootpersistentVolumeClaim:claimName: my-pvc---apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: my-pvc
spec:accessModes: - ReadWriteManyresources:requests:storage: 5Gi [root@master pv-pvc]
apiVersion: v1
kind: PersistentVolume
metadata:name: my-pv
spec:capacity:storage: 5GiaccessModes:- ReadWriteManynfs:path: /data/nfsserver: 192.168.174.131
2.2 绑定PV
[root@master pv-pvc]
persistentvolume/my-pv created
[root@master pv-pvc]
deployment.apps/nginx-dep1 created
persistentvolumeclaim/my-pvc created[root@master pv-pvc]
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/my-pv 5Gi RWX Retain Bound default/my-pvc 70sNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/my-pvc Bound my-pv 5Gi RWX 67s
[root@master pv-pvc]
NAME READY STATUS RESTARTS AGE
nginx-dep1-69f5bb95b-jsf79 1/1 Running 0 54s
nginx-dep1-69f5bb95b-tj9hb 1/1 Running 0 54s
nginx-dep1-69f5bb95b-vvnrq 1/1 Running 0 54s
2.3 强制删除pv,pvc
$ kubectl patch pv xxx -p '{"metadata":{"finalizers":null}}'
$ kubectl patch pvc xxx -p '{"metadata":{"finalizers":null}}'
2.4 测试
root@nginx-dep1-69f5bb95b-jsf79:/
index.html