kubetnetes 之存储 PV PVC

概述

k8s最初用于管理无状态的服务，单随着越来越多的应用迁移的k8s平台，管理存储资源成为一个非常重要的功能。

k8s使用两种资源管理存储： PersistentVolume（一些简称PV）：由管理员添加的的一个存储的描述，是一个全局资源，包含存储的类型，存储的大小和访问模式等。它的生命周期独立于Pod，例如当使用它的Pod销毁时对PV没有影响。 PersistentVolumeClaim（一些简称PVC）：是Namespace里的资源，描述对PV的一个请求。请求信息包含存储大小，访问模式等。

PV 和 PVC生命周期

PV是k8s集群里的存储，PVC会使用PV，它们的生命周期概况如下：

Provisioning

PV可以通过两种方式提供： Static：管理员在集群里创建PV资源，每个PV包含详细的真实存储的信息供PVC使用。 Dynamic：当集群里没有PV符合PVC请求时，集群会尝试动态生成PV。前提是管理员提供过StorageClass资源并且PVC里有StorageClass的描述。

Binding

当集群中新添加一个PVC时，k8s里的PVController（下一篇文章介绍）会试图查找最合适（存储大小和访问模式）的PV并建立绑定关系。 最合适的意思是PVC一定满足PV的要求，单也可能比PVC要求的要多，例如PVC请求5G存储，但当前最小的PV是10G，那么这个PV也会被分配给PVC。 注意一个PV只能绑定给一个PVC。

Using

Pods把PVC当做Volume（类似于Docker的Volume）使用，下面会有例子介绍怎样在Pod中使用PVC。K8s会解析Pod，PV和PVC的联系，把PV中的存储挂载到Pod中。

Releasing

当用户使用完PVC可以把它删除，绑定在其上的PV会变成“released”并准备被回收。

Reclaiming

有三种回收策略： * Retained：PV会保持原有数据并允许用户手动回收数据。 * Recycled：删除数据（rm -rf /thevolume/*）并允许PV被绑定到其它PVC。 * Deleted： 删除数据并删除PV。

PV

PV在k8s中被实现成插件，可以非常方便的扩展新的存储类型。已经被支持的类型包含所有主流的存储方案： * GCEPersistentDisk * AWSElasticBlockStore * AzureFile * AzureDisk * FC (Fibre Channel) * Flocker * NFS * iSCSI * RBD (Ceph Block Device) * CephFS * Cinder (OpenStack block storage) * Glusterfs * VsphereVolume * Quobyte Volumes * HostPath (single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster) * VMware Photon

PV 资源描述

每个PV里包含一个spec和status apiVersion: v1 kind: PersistentVolume metadata: name: pv0003 spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle nfs: path: /tmp server: 172.17.0.2

Capacity

通过capacity给PV设置特定的大小。

Access Modes

k8s不会真正检查存储的访问模式或根据访问模式做访问限制，只是对真实存储的描述，最终的控制权在真实的存储端。目前支持三种访问模式： * ReadWriteOnce – PV以 read-write 挂载到一个节点 * ReadOnlyMany – PV以read-only方式挂载到多个节点 * ReadWriteMany – PV以read-write方式挂载到多个节点

Reclaim

当前支持的回收策略: * Retain – 允许用户手动回收 * Recycle – 删除PV上的数据 (“rm -rf /thevolume/*”) * Delete – 删除PV

Phase

Available – PV可以被使用 Bound – PV被绑定到PVC Released – 被绑定的PVC被删除，可以被Reclaim Failed – 自动回收失败

PVC资源描述

每个PVC里包含一个spec和status，访问模式和请求的大小类似于PV。 kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 8Gi

Phase

• Pending – 等待可用的PV
• Bound – PV被绑定到PVC
• Lost – 找不到绑定的PV

实例

运行实例

通过命令行添加如下三个资源： 1. 添加PV

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
- ReadWriteMany
- ReadOnlyMany
nfs:
path: /var/nfsshare/v1
server: 172.16.51.58
persistentVolumeReclaimPolicy: Delete

2. 添加PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
namespace: test
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
  storage: 5Gi

3. 添加Pod

kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: myfrontend
  image: dockerfile/nginx
  volumeMounts:
  - mountPath: "/var/www/html"
    name: mypd
volumes:
- name: mypd
  persistentVolumeClaim:
    claimName: myclaim

查看PV和PVC资源状态

当实例正常运行以后查看各个资源的状态 1. PV 状态变成Bound

...
status:
phase: Bound

2. PVC 状态变成Bound

...
volumeName: pv3
status:
accessModes:
- ReadWriteOnce
- ReadWriteMany
- ReadOnlyMany
capacity:
storage: 5Gi
phase: Bound