kubernetes系列11—PV和PVC详解

时间 2019-11-06

标签 kubernetes 系列 pvc 详解繁體版

原文原文链接

一、认识PV/PVC/StorageClass

1.1 介绍

　　管理存储是管理计算的一个明显问题。该PersistentVolume子系统为用户和管理员提供了一个API，用于抽象如何根据消费方式提供存储的详细信息。为此，咱们引入了两个新的API资源：PersistentVolume和PersistentVolumeClaimnode

　　PersistentVolume（PV）是集群中由管理员配置的一段网络存储。它是集群中的资源，就像节点是集群资源同样。 PV是容量插件，如Volumes，但其生命周期独立于使用PV的任何单个pod。此API对象捕获存储实现的详细信息，包括NFS，iSCSI或特定于云提供程序的存储系统。nginx

　　PersistentVolumeClaim（PVC）是由用户进行存储的请求。它相似于pod。 Pod消耗节点资源，PVC消耗PV资源。Pod能够请求特定级别的资源（CPU和内存）。声明能够请求特定的大小和访问模式（例如，能够一次读/写或屡次只读）。vim

　　虽然PersistentVolumeClaims容许用户使用抽象存储资源，可是PersistentVolumes对于不一样的问题，用户一般须要具备不一样属性（例如性能）。群集管理员须要可以提供各类PersistentVolumes不一样的方式，而不只仅是大小和访问模式，而不会让用户了解这些卷的实现方式。对于这些需求，有StorageClass 资源。api

　　StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。不一样的类可能映射到服务质量级别，或备份策略，或者由群集管理员肯定的任意策略。 Kubernetes自己对于什么类别表明是不言而喻的。这个概念有时在其余存储系统中称为“配置文件”。bash

　　PVC和PV是一一对应的。服务器

1.2 生命周期

　　PV是群集中的资源。PVC是对这些资源的请求，而且还充当对资源的检查。PV和PVC之间的相互做用遵循如下生命周期：网络

Provisioning ——-> Binding ——–>Using——>Releasing——>Recyclingapp

供应准备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使用，须要插件支持。

注：目前只有NFS和HostPath类型卷支持回收策略，AWS EBS,GCE PD,Azure Disk和Cinder支持删除(Delete)策略。curl

1.3 PV类型

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 (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
Portworx Volumes
ScaleIO Volumes
StorageOS

1.4 PV卷阶段状态

Available – 资源还没有被claim使用
Bound – 卷已经被绑定到claim了
Released – claim被删除，卷处于释放状态，但未被集群回收。
Failed – 卷自动回收失败

二、演示：建立PV

nfs服务器在上一篇已经部署，详情请看上一篇博客。

2.1 准备nfs服务

（1）在nfs服务器上先创建存储卷对应的目录

[root@nfs ~]# cd /data/volumes/
[root@nfs volumes]# mkdir v{1,2,3,4,5}
[root@nfs volumes]# ls
index.html  v1  v2  v3  v4  v5
[root@nfs volumes]# echo "<h1>NFS stor 01</h1>" > v1/index.html 
[root@nfs volumes]# echo "<h1>NFS stor 02</h1>" > v2/index.html 
[root@nfs volumes]# echo "<h1>NFS stor 03</h1>" > v3/index.html 
[root@nfs volumes]# echo "<h1>NFS stor 04</h1>" > v4/index.html 
[root@nfs volumes]# echo "<h1>NFS stor 05</h1>" > v5/index.html

（2）修改nfs的配置

[root@nfs volumes]# vim /etc/exports
/data/volumes/v1        192.168.130.0/24(rw,no_root_squash)
/data/volumes/v2        192.168.130.0/24(rw,no_root_squash)
/data/volumes/v3        192.168.130.0/24(rw,no_root_squash)
/data/volumes/v4        192.168.130.0/24(rw,no_root_squash)
/data/volumes/v5        192.168.130.0/24(rw,no_root_squash)

（3）查看nfs的配置

[root@nfs volumes]# exportfs -arv
exporting 192.168.130.0/24:/data/volumes/v5
exporting 192.168.130.0/24:/data/volumes/v4
exporting 192.168.130.0/24:/data/volumes/v3
exporting 192.168.130.0/24:/data/volumes/v2
exporting 192.168.130.0/24:/data/volumes/v1

（4）是配置生效

[root@nfs volumes]# showmount -e
Export list for nfs:
/data/volumes/v5 192.168.130.0/24
/data/volumes/v4 192.168.130.0/24
/data/volumes/v3 192.168.130.0/24
/data/volumes/v2 192.168.130.0/24
/data/volumes/v1 192.168.130.0/24

2.2 在master上建立PV

（1）编写yaml文件，并建立pv

建立5个pv，存储大小各不相同，是否可读也不相同

[root@master volumes]# vim pv-damo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /data/volumes/v1
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /data/volumes/v2
    server: nfs
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 5Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /data/volumes/v3
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 20Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /data/volumes/v4
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 10Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /data/volumes/v5
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 15Gi
[root@master volumes]# kubectl apply -f pv-damo.yaml
persistentvolume/pv001 created
persistentvolume/pv002 created
persistentvolume/pv003 created
persistentvolume/pv004 created
persistentvolume/pv005 created

（2）查询验证

[root@master ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
pv001     5Gi        RWO,RWX        Retain           Available                                      9s
pv002     5Gi        RWO            Retain           Available                                      9s
pv003     5Gi        RWO,RWX        Retain           Available                                      9s
pv004     10Gi       RWO,RWX        Retain           Available                                      9s
pv005     15Gi       RWO,RWX        Retain           Available                                      9s

三、建立PVC，绑定PV

（1）编写yaml文件，并建立pvc

建立一个pvc，须要6G存储；因此不会匹配pv001、pv002、pv003

[root@master volumes]# vim vol-pvc-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
  namespace: default
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 6Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: vol-pvc
  namespace: default
spec:
  volumes:
  - name: html
    persistentVolumeClaim:
      claimName: mypvc
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html/
[root@master volumes]# kubectl apply -f vol-pvc-demo.yaml
persistentvolumeclaim/mypvc created
pod/vol-pvc created

（2）查询验证：pvc已经绑定到pv004上

[root@master ~]# kubectl get pvc
NAME      STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mypvc     Bound     pv004     10Gi       RWO,RWX                       24s
[root@master ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON    AGE
pv001     5Gi        RWO,RWX        Retain           Available                                            1m
pv002     5Gi        RWO            Retain           Available                                            1m
pv003     5Gi        RWO,RWX        Retain           Available                                            1m
pv004     10Gi       RWO,RWX        Retain           Bound       default/mypvc                            1m
pv005     15Gi       RWO,RWX        Retain           Available                                            1m

（3）查询业务验证

[root@master ~]# kubectl get pods -o wide
NAME      READY     STATUS    RESTARTS   AGE       IP             NODE
vol-pvc   1/1       Running   0          59s       10.244.2.117   node2
[root@master ~]# curl 10.244.2.117
<h1>NFS stor 04</h1>

　　本篇原本还想再写2个特点的存储卷 configmap和secret 的解析和使用，可是博主今天又些急事，改天在下一篇补上；本篇内容有些少，还望你们见谅~