PV/PVC/StorageClass
管理存储是管理计算的一个明显问题。该PersistentVolume子系统为用户和管理员提供了一个API，用于抽象如何根据消费方式提供存储的详细信息。为此，我们引入了两个新的API资源：PersistentVolume和PersistentVolumeClaim。
A PersistentVolume（PV）是群集中的一块存储，由管理员配置或使用存储类动态配置。它是集群中的资源，就像节点是集群资源一样。PV是容量插件，如Volumes，但其生命周期独立于使用PV的任何单个pod。此API对象捕获存储实现的详细信息，包括NFS，iSCSI或特定于云提供程序的存储系统。
甲PersistentVolumeClaim（PVC）是由用户进行存储的请求。它类似于一个pods。Pod消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（例如，可以一次读/写或多次只读）。
最终实现数据的持久化
PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 提供了方便的持久化卷：PV 提供网络存储资源，而 PVC 请求存储资源。这样，设置持久化的工作流包括配置底层文件系统或者云数据卷、创建持久性数据卷、最后创建 PVC 来将 Pod 跟数据卷关联起来。PV 和 PVC 可以将 pod 和数据卷解耦，pod 不需要知道确切的文件系统或者支持它的持久化引擎，pvc 定义PV 。通过声明方式让 pod 调用。
Volume 生命周期
Volume 生命周期
Volume 的生命周期包括 5 个阶段
Provisioning，即 PV 的创建，可以直接创建 PV（静态方式），也可以使用 StorageClass 动态创建
Binding，将 PV 分配给 PVC
Using，Pod 通过 PVC 使用该 Volume，并可以通过准入控制 StorageObjectInUseProtection（1.9 及以前版本为 PVCProtection）阻止删除正在使用的 PVC
Releasing，Pod 释放 Volume 并删除 PVC
Reclaiming，回收 PV，可以保留 PV 以便下次使用，也可以直接从云存储中删除
Deleting，删除 PV 并从云存储中删除后段存储
根据这 5 个阶段，Volume 的状态有以下 4 种
Available：可用
Bound：已经分配给 PVC
Released：PVC 解绑但还未执行回收策略
Failed：发生错误
使用NFS 测试
[root@kube yum.repos.d]# yum install -y nfs-utils //安装服务 Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile Resolving Dependencies ....... [root@kube data]# cat /etc/exports //编辑配置文件 /nfs/data 10.2.61.0/24(rw,no_root_squash,sync) [root@kube data]# #启动服务 systemctl restart rpcbind && systemctl enable rpcbind systemctl restart nfs && systemctl enable nfs
//安装客户端也是通过 yum install -y nfs-utils
nfs 创建多个挂载点
[root@kube data]# exportfs /nfs/data/v1 10.2.61.0/24 /nfs/data/v2 10.2.61.0/24 /nfs/data/v3 10.2.61.0/24 /nfs/data/v4 10.2.61.0/24 /nfs/data/v5 10.2.61.0/24 /nfs/data/v6 10.2.61.0/24 /nfs/data/v7 10.2.61.0/24 /nfs/data/v8 10.2.61.0/24 /nfs/data/v9 10.2.61.0/24 [root@kube data]# [root@kube data]# systemctl restart rpcbind && systemctl restart nfs [root@kube data]#
创建PV
[root@kube pv-pvc]# cat p1.yaml apiVersion: v1 kind: PersistentVolume metadata: name: pv0001 spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: slow nfs: path: /nfs/data/v1 server: 10.2.61.21 [root@kube pv-pvc]# [root@kube pv-pvc]# kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv0001 5Gi RWO Recycle Available slow 20s [root@kube pv-pvc]#
PV 的访问模式（accessModes）有三种：PV 的访问模式（accessModes）有三种：
ReadWriteOnce（RWO）：是最基本的方式，可读可写，但只支持被单个节点挂载。
ReadOnlyMany（ROX）：可以以只读的方式被多个节点挂载。
ReadWriteMany（RWX）：这种存储可以以读写的方式被多个节点共享。不是每一种存储都支持这三种方式，像共享方式，目前支持的还比较少，比较常用的是 NFS。在 PVC 绑定 PV 时通常根据两个条件来绑定，一个是存储的大小，另一个就是访问模式。
PV 的回收策略
PV 的回收策略（persistentVolumeReclaimPolicy，即 PVC 释放卷的时候 PV 该如何操作）也有三种 Retain，不清理, 保留 Volume（需要手动清理） Recycle，删除数据，即 rm -rf /thevolume/*（只有 NFS 和 HostPath 支持） Delete，删除存储资源，比如删除 AWS EBS 卷（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持）
上面通过手动的方式创建了一个 NFS Volume，这在管理很多 Volume 的时候不太方便。Kubernetes 还提供了 StorageClass 来动态创建 PV，不仅节省了管理员的时间，还可以封装不同类型的存储供 PVC 选用。
StorageClass 包括四个部分
-
provisioner：指定 Volume 插件的类型，包括内置插件（如
kubernetes.io/glusterfs）和外部插件（如 external-storage 提供的ceph.com/cephfs）。 -
mountOptions：指定挂载选项，当 PV 不支持指定的选项时会直接失败。比如 NFS 支持
hard和nfsvers=4.1等选项。 -
parameters：指定 provisioner 的选项，比如
kubernetes.io/aws-ebs支持type、zone、iopsPerGB等参数。 -
reclaimPolicy：指定回收策略，同 PV 的回收策略。
在使用 PVC 时，可以通过 DefaultStorageClass 准入控制设置默认 StorageClass, 即给未设置 storageClassName 的 PVC 自动添加默认的 StorageClass。而默认的 StorageClass 带有 annotation storageclass.kubernetes.io/is-default-class=true。
创建 PVC
PV 是存储资源，而 PersistentVolumeClaim (PVC) 是对 PV 的请求。PVC 跟 Pod 类似：Pod 消费 Node 资源，而 PVC 消费 PV 资源；Pod 能够请求 CPU 和内存资源，而 PVC 请求特定大小和访问模式的数据卷。
[root@kube pv-pvc]# cat pvc-demo.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 2Gi storageClassName: slow [root@kube pv-pvc]# [root@kube pv-pvc]# vim pvc-demo.yaml [root@kube pv-pvc]# kubectl apply -f pvc-demo.yaml persistentvolumeclaim/my-pvc created [root@kube pv-pvc]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE my-pvc Bound pv0001 5Gi RWO slow 12s
[root@kube pv-pvc]# kubectl get pv //pv 已经被pvc 绑定 NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv0001 5Gi RWO Recycle Bound default/my-pvc slow 22h [root@kube pv-pvc]#
pod 调用pvc
[root@kube pv-pvc]# cat pod-vol-pvc-demo.yaml apiVersion: v1 kind: Pod metadata: name: pod-vol-pvc spec: containers: - name: myapp image: nginx volumeMounts: - name: html mountPath: /usr/share/nginx/html/ volumes: //配置 volumes 调用 pvc - name: html persistentVolumeClaim: claimName: my-pvc [root@kube pv-pvc]# ] [root@kube v1]# kubectl describe pods pod-vol-pvc Name: pod-vol-pvc Namespace: default Priority: 0 Node: kube.node1/10.2.61.22 Start Time: Wed, 28 Aug 2019 16:32:50 +0800 Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"pod-vol-pvc","namespace":"default"},"spec":{"containers":[{"image":"n... Status: Running IP: 10.244.2.49 Containers: myapp: Container ID: docker://3af79a56926f85c076d35dcaba50af659aa362fa453b4e2b969d3150b44169eb Image: nginx Image ID: docker-pullable://nginx@sha256:53ddb41e46de3d63376579acf46f9a41a8d7de33645db47a486de9769201fec9 Port: <none> Host Port: <none> State: Running Started: Wed, 28 Aug 2019 16:33:12 +0800 Ready: True Restart Count: 0 Environment: <none> Mounts: /usr/share/nginx/html/ from html (rw) /var/run/secrets/kubernetes.io/serviceaccount from default-token-bsthb (ro) Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: html: Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) ClaimName: my-pvc ReadOnly: false default-token-bsthb: Type: Secret (a volume populated by a Secret) SecretName: default-token-bsthb Optional: false QoS Class: BestEffort