kubernetes系列(十四) - 存储之PersistentVolume

时间 2020-07-11

标签 kubernetes 系列十四存储 persistentvolume 繁體版

原文原文链接

1. PersistentVolume(PV)简介

1.1 为何须要Persistent Volume(PV)

在讲PersistentVolume(PV)以前，咱们须要先讲一下Volumehtml

Volume详情可见上一章： kubernetes系列(十三) - 存储之Volume
nginx

Volume是被定义在pod上的(emptyDir或者hostPath)，属于计算资源的一部分。因此Volume是有局限性的，由于在实际的运用过程当中，咱们一般会先定义一个网络存储，而后从中划出一个网盘并挂接到虚拟机上。web

为了屏蔽底层存储实现的细节，让用户方便使用，同时让管理员方便管理。Kubernetes从V1.0版本就引入了PersistentVolume(PV)和与之相关联的PersistentVolumeClaim(PVC)两个资源对象来实现对存储的管理shell

1.2 PersistentVolume(PV)和Volume的区别

PV能够被理解成kubernetes集群中的某个网络存储对应的一块存储，它与Volume相似，可是有以下的区别：api

PV只能是网络存储，不属于任何Node，可是能够在每一个Node上访问
PV不是被定义在pod上，而是独立在pod以外被定义的。
- 意味着pod被删除了，PV仍然存在，这点与Volume不一样

1.3 PV和PVC更具体的概念和关系

1.3.1 PersistentVolume(PV)

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

1.3.2 PersistentVolumeClaim(PVC)

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

1.3.3 PV和PVC的关系和图解

pvc是一种pv的请求方案，PVC定义我当前须要什么样类型的PV，而后会自动在当前存在的pv中选取一个匹配度最高的pvapp

一个PVC只能绑定一个PV！！less

2. PersistentVolume(PV)的分类

2.1 静态PV

简单来讲spa

由集群管理员手动建立的一些PV

完整的概念

集群管理员建立一些PV。它们带有可供群集用户使用的实际存储的细节。它们存在于KubernetesAPl中，可用于消费。

2.2 动态PV

简单来讲

配置了容许动态PV的策略后，若是当前存在的PV没法知足PVC的要求，则会动态建立PV.

动态PV了解便可

完整的概念

当管理员建立的静态PV都不匹配用户的PersistentVolumeClaim时，集群可能会尝试动态地为PVC建立卷。此配置基于StorageClasses,因此要启用基于存储级别的动态存储配置要求：

PVC必须请求StorageClasses
管理员必须建立并配置StorageClasses才能进行动态建立
声明该类为“”能够有效地禁用其动态配置
集群管理员须要启用API server上的DefaultStorageClass[准入控制器]。例如，经过确保DefaultStorageClass位于API server 组件的--admission-control标志，使用逗号分隔的有序值列表中，能够完成此操做

3. PersistentVolumeClaim(PVC)的保护

PVC保护的目的是确保由pod正在使用的PVC不会从系统中移除，由于若是被移除的话可能会致使数据丢失当启用PVC保护alpha功能时，若是用户删除了一个pod正在使用的PVC，则该PVC不会被当即删除。PVC的删除将被推迟，直到PVC再也不被任何 pod使用

4. PersistentVolume(PV)支持的底层存储类型

PersistentVolume类型以插件形式实现. kubernetes目前支持如下类型(排名不分前后):

跟上一集中的volume支持的类型差很少

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 Scalelo Volumes StorageOS

5. PersistentVolume(PV)的资源清单

5.1 资源清单示例

apiVersion: v1 
kind: PersistentVolume 
metadata:
  name：pve003 
spec:
  capacity:
    # 卷的大小为5G
    storage: 5Gi 
  # 存储卷的类型为：文件系统
  volumeMode: Filesystem 
  # 访问策略：该卷能够被单个节点以读/写模式挂载
  accessModes:
    - ReadNriteOnce 
  # 回收策略：回收
  persistentVolumeReclaimPolicy: Recycle
  # 对应的具体底层存储的分级
  # 好比有些固态或者其余存储类型比较快，就能够定义为strong
  storageClassName: slow
  # (可选的)挂载选项
  mountOptions:
    - hard 
    - nfsvers=4.1
  # 具体对应的真实底层存储类型为nfs
  # 挂载到172服务器下的/tmp目录
  nfs:
    path: /tmp 
    server: 172.17.0.2

5.2 PV的访问模式(spec.accessModes)

5.2.1 三种访问模式

访问模式accessModes一共有三种：

ReadWriteOnce: 该卷能够被单个节点以读/写模式挂载
ReadOnlyMany: 该卷能够被多个节点以只读模式挂载
ReadWriteMany: 该卷能够被多个节点以读/写模式挂载

在命令行cli中，三种访问模式能够简写为：

RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany

但不是全部的类型的底层存储都支持以上三种，每种底层存储类型支持的都不同！！

5.2.2 各类底层存储具体支持的访问模式

Volume Plugin	ReadWriteOnce	ReadOnlyMany	ReadWriteMany
AWSElasticBlockStore	✓	-	-
AzureFile	✓	✓	✓
AzureDisk	✓	-	-
CephFS	✓	✓	✓
Cinder	✓	-	-
FC	✓	✓	-
FlexVolume	✓	✓	-
Flocker	✓	-	-
GCEPersistentDisk	✓	✓	-
Glusterfs	✓	✓	✓
HostPath	✓	-	-
iSCSI	✓	✓	-
PhotonPersistentDisk	✓	-	-
Quobyte	✓	✓	✓
NFS	✓	✓	✓
RBD	✓	✓	-
VsphereVolume	✓	-	-
PortworxVolume	✓	-	✓
ScaleIO	✓	✓	-

5.3 PV的回收策略(spec.persistentVolumeReclaimPolicy)

5.3.1 回收策略的三种策略

Retain(保留): pv被删除后会保留内存，手动回收
Recycle(回收): 删除卷下的全部内容（rm-rf /thevolume/*)
Delete(删除): 关联的存储资产（例如AWS EBS、GCE PD、Azure Disk 和OpenStack Cinder卷）将被删除。即直接把卷给删除了

5.3.2 回收策略注意事项

当前，只有NFS和HostPath支持Recycle回收策略

最新版本中的Recycle已被废弃，截图以下

附：具体官网文档详细说明连接点击此处

AWS EBS、GCE PD、Azure Disk 和Cinder 卷支持Delete删除策略

6. PersistentVolume(PV)的状态

PV能够处于如下的某种状态：

Available(可用): 块空闲资源尚未被任何声明绑定
Bound(已绑定): 卷已经被声明绑定, 注意：可是不必定不能继续被绑定，看accessModes而定
Released(已释放): 声明被删除，可是资源还未被集群从新声明
Failed(失败): 该卷的自动回收失败

命令行会显示绑定到PV的PVC的名称

7. 实验-持久化演示说明-NFS

注：如下内容笔者没有实际尝试过，仅作记录使用

7.1 安装NFS服务器

yum install -y nfs-common nfs-utils rpcbind 
mkdir /nfsdata 
chmod 777 /nfsdata 
chown nfsnobody /nfsdata 
cat /etc/exports /nfsdata *(rw,no_root_squash,no_all_squash,sync)
systemctl start rpcbind 
systemctl start nfs

7.2 在其余节点上安装客户端

yum -y install nfs-utils rpcbind
mkdir /test
showmount -e 192.168.66.100
mount -t nfs 192.168.66.100:/nfsdata /test/
cd /test/
ls
umount /test/

7.3 部署PV

apiVersion: v1 
kind: PersistentVolume 
metadata:
  name: nfspv1 
spec:
  capacity:
    storage: 10Gi 
  accessModes:
    - ReadWriteOnce 
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
   path: /nfsdata
   server: 192.168.66.100

7.4 建立服务并使用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"
  replicas: 3 
  template:
    metadata:
      labels:
        app: nginx 
    spec:
      containers:
      - name: nginx 
        image: k8s.gcr.io/nginx-slim:0.8 
        ports:
        - containerPort: 80 
          name: web 
        volumeMounts:
        - name: www 
          mountPath: /usr/share/nginx/html 
  volumeClaimTemplates:
  - metadata:
      name: www 
    spec:
      accessModes: [ "ReadWriteOnce" ] 
      storageClassName: "nfs"
      resources:
        requests:
          storage: 1Gi

8. 关于 Statefulset

StatefulSet为每一个Pod副本建立了一个DNS域名，这个域名的格式为:S(podname).(headless servername)

也就意味着服务间是经过Pod域名来通讯而非PodIP，由于当Pod所在Node发生故障时，Pod会被飘移到其它 Node上,PodIP会发生变化，可是Pod域名不会有变化

StatefulSet使用Headless服务来控制Pod的域名，这个域名的FQDN为:S(servicename).$(namespace).svc.cluster.local

其中，“cluster.local”指的是集群的域名

根据volumeClaimTemplates，为每一个Pod 建立一个pvo,pvc的命名规则匹配模式:
(volumeClaimTemplates.name)-(pod_name)

好比上面的 volumeMounts.name=www,Podname-web-[0-2]，所以建立出来的PVC是 www-web-0、www-web-一、 www-web-2

删除 Pod 不会删除其pvc，手动删除 pvc将自动释放pv
Statefulset的启停顺序:
- 有序部署:部罢Statefulset时，若是有多个Pod副本，它们会被顺序地建立（从0到N-1)而且，在下一个Pod运行以前全部以前的Pod必须都是Running和Ready状态。
- 有序删除:当Pod被删除时，它们被终止的顺序是从N-1到0。
- 有序扩展:当对Pod执行扩展操做时，与部署同样，它前面的Pod必须都处于Running和Ready状态。
Statefulset使用场景:
- 稳定的持久化存储，即Pod从新调度后仍是能访问到相同的持久化数据，基于PVC 来实现。
- 稳定的网络标识符，即Pod 从新调度后其iPodName 和 HostName不变。
- 有序部署，有序扩展，基于init containers 来实现。
- 有序收缩。