k8s-----20、持久化存储--PV/PVC

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]# kubectl delete -f nfs-nginx.yaml  #先删除nfs章节中创建的pod，但是svc不用删除
[root@master nfs-nfinx]# kubectl get svc
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]# cat pvc.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-dep1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - name: wwwroot
          mountPath: /usr/share/nginx/html
        ports:
        - containerPort: 80
      volumes:
      - name: wwwroot
        persistentVolumeClaim:
          claimName: my-pvc

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:   #匹配模式
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi  #存储资源

[root@master pv-pvc]# cat pv.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /data/nfs
    server: 192.168.174.131

2.2 绑定PV

[root@master pv-pvc]# kubectl apply -f pv.yaml 
persistentvolume/my-pv created
[root@master pv-pvc]# kubectl apply -f pvc.yaml 
deployment.apps/nginx-dep1 created
persistentvolumeclaim/my-pvc created


[root@master pv-pvc]# kubectl get pv,pvc   ##查看是否绑定
NAME                     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
persistentvolume/my-pv   5Gi        RWX            Retain           Bound    default/my-pvc                           70s

NAME                           STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/my-pvc   Bound    my-pv    5Gi        RWX                           67s
[root@master pv-pvc]# kubectl get pod   ##查看pod
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 测试

##进入pod中查看
root@nginx-dep1-69f5bb95b-jsf79:/# ls /usr/share/nginx/html/
index.html