k8s pv-pvc

k8s pv-pvc

1.1 简介

自己搭建

云供应商的则会提供文档，直接提供PV

1.1.1 PersistentVolume（PV）

是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统

1.1.2 PersistentVolumeClaim（PVC）

是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或 只读多次模式挂载

1.1.3 静态 pv

集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中，可用于消费，就好比我们后端有个5G的硬盘，存储需要4.6G，选择器选择它后，会浪费0.4G资源，所以有了动态 pv

1.1.4 动态

当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时，集群可能会尝试动态地为 PVC 创建卷。此配置基于 StorageClasses：PVC 必须请求 [存储类]，并且管理员必须创建并配置该类才能进行动态创建。声明该类为 "" 可以有效地禁用其动态配置

要启用基于存储级别的动态存储配置，集群管理员需要启用 API server 上的 DefaultStorageClass [准入控制器] 。例如，通过确保 DefaultStorageClass 位于 API server 组件的 --admission-control 标志，使用逗号分隔的有序值列表中，可以完成此操作

1.1.5 绑定

master 中的控制环路监视新的 PVC，寻找匹配的 PV（如果可能），并将它们绑定在一起。如果为新的 PVC 动态调配 PV，则该环路将始终将该 PV 绑定到 PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量。一旦 PV 和 PVC 绑定后，PersistentVolumeClaim 绑定是排他性的，不管它们是如何绑定的。 PVC 跟 PV 绑定是一对一的映射

2.1 持久化卷声明的保护

PVC 保护的目的是确保由 pod 正在使用的 PVC 不会从系统中移除，因为如果被移除的话可能会导致数据丢失
注意：当 pod 状态为 Pending 并且 pod 已经分配给节点或 pod 为 Running 状态时，PVC 处于活动状态

当启用PVC 保护 alpha 功能时，如果用户删除了一个 pod 正在使用的 PVC，则该 PVC 不会被立即删除。PVC 的删除将被推迟，直到 PVC 不再被任何 pod 使用.删除的顺序应该需要先删除Pod，再删除PVC，最后删除PV

3.1 持久化卷类型

• GCEPersistentDisk AWSElasticBlockStore AzureFile AzureDisk FC (Fibre Channel)
• FlexVolume Flocker NFS iSCSI RBD (Ceph Block Device) CephFS
• Cinder (OpenStack block storage) Glusterfs VsphereVolume Quobyte Volumes
• **HostPath ** VMware Photon Portworx Volumes ScaleIO Volumes StorageOS

持久卷演示代码

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

4.1 PV 访问模式

PersistentVolume 可以以资源提供者支持的任何方式挂载到主机上。如下表所示，供应商具有不同的功能，每个 PV 的访问模式都将被设置为该卷支持的特定模式。例如，NFS 可以支持多个读/写客户端，但特定的 NFS PV 可能以只读方式导出到服务器上。每个 PV 都有一套自己的用来描述特定功能的访问模式:

• ReadWriteOnce——该卷可以被单个节点以读/写模式挂载
• ReadOnlyMany——该卷可以被多个节点以只读模式挂载
• ReadWriteMany——该卷可以被多个节点以读/写模式挂载

在命令行中，访问模式缩写为：

• RWO - ReadWriteOnce
• ROX - ReadOnlyMany
• RWX - ReadWriteMany

一个卷一次只能使用一种访问模式挂载，即使它支持很多访问模式。例如，GCEPersistentDisk 可以由单个节点作为 ReadWriteOnce 模式挂载，或由多个节点以 ReadOnlyMany 模式挂载，但不能同时挂载

5.1 回收策略

• Retain（保留）——手动回收，删除pod和pvc后，pv进入reset状态，等待运维人员取走里面的数据，然后手动删除，目前最多使用的模式
• Recycle（回收）——基本擦除（rm -rf /thevolume/*），删除pod和pvc后，pv自己清除目录下所有内容，然后再被其他pv绑定，不建议使用
• Delete（删除）——关联的存储资产（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）将被删除，相当于解除pvc和云供应商的pv解除绑定，省下流量和钱
  当前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持删除策略

6.1 状态

卷可以处于以下的某种状态：

• Available（可用）——一块空闲资源还没有被任何声明绑定
• Bound（已绑定）——卷已经被声明绑定
• Released（已释放）——声明被删除，但是资源还未被集群重新声明
• Failed（失败）——该卷的自动回收失败
  命令行会显示绑定到 PV 的 PVC 的名称

7.1 持久化演示说明 - NFS

7.1.1 安装 NFS 服务器

//k8s和node节点都要装
yum install -y nfs-common nfs-utils  rpcbind

//登陆nfs的机器
yum install -y nfs-common nfs-utils  rpcbind
mkdir /nfsdata
//多创建几个共享
for i in {1..5};do mkdir -p $i;echo $i > $i/index.html;done
//这里权限你们可以自己决定
chmod 777 -R /nfsdata
//修改配置文件
for i in {1..5};do echo "/nfsdata/${i} *(rw,no_root_squash,no_all_squash,sync)" >> /etc/exports;done

systemctl restart rpcbind
systemctl restart nfs
systemctl enable rpcbind
systemctl enable nfs


//在别的机器上测试nfs
 mkdir -p test
 //挂载到nfs
 mount -t nfs 192.168.50.122:/nfsdata/1 test
 //远程挂载到nfs的1的目录下，可以新建和修改文件
 cd test;touch aaa;echo 0 > index.html
 //解除挂载,nfs那边新建的文件和修改的文件已经生效
 cd ..;umount test

7.1.2 部署 PV

spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs			//注意这里，和下面pvc对应
  nfs:
    path: /nfsdata/1
    server: 192.168.50.122
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv2
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /nfsdata/2
    server: 192.168.50.122
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv3
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /nfsdata/3
    server: 192.168.50.122

kubectl create -f aaa.yaml
kubectl get pv

7.1.3 创建服务并使用 PVC

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None		//注意这里的无头服务，没有类型
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"		//这里的serviceName是无头服务的name
  replicas: 3		//这里3个副本，副本会依次等第1个成功运行才会运行第二个，第三个
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: wangyanglinux/myapp:v1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs"   	//注意这里，和上面pv对应
      resources:
        requests:
          storage: 1Gi  

kubectl get pv,pvc
//可以看到，第三个因为策略不匹配，没有pv可以和它匹配，一直处于pending状态
kubectl edit statefulSet web	//修改statefuleSet的yaml

//当有多个pv时，控制器会先将一部分符合大小的pv作为预选，然后选择一个大小最合适不浪费资源的作为优选，部署到这个pv上
//类必须一样，读写类型一样，大小选择最合适的

数据持久化到nfs了，即使pod重启，也不会切换了

7.1.4 删除pvc

删除容器和pvc后，可以看到pv都是Released状态然后mount到nfs上，查看保留哪些信息

//删除容器
kubectl delete statefulSet --all
//删除pvc
 kubectl delete pvc --all

如果我们想恢复数据，然后mount到nfs上，查看保留哪些信息

//查看pv的nfs信息
kubectl get pv nfspv1  -o yaml
//挂载数据到test，可以把test数据备份出来
mkdir -p /test;mount -t nfs 192.168.50.122:/nfsdata/1 /test/
//然后解除挂载
cd ..;umount /test/

这时候，可以看到pv还是Released状态无法再挂载新的pvc，有两种解决方法

• 删除pv，然后重新创建pv，但是比较麻烦
• 清除pv的记忆，让他忘记和哪个pvc挂载过

  kubectl edit pv  nfspv1
  

可以看到已经Available可用了