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

• 1. PersistentVolume(PV)简介
  • 1.1 为什么需要Persistent Volume(PV)
  • 1.2 PersistentVolume(PV)和Volume的区别
  • 1.3 PV和PVC更具体的概念和关系
    • 1.3.1 PersistentVolume(PV)
    • 1.3.2 PersistentVolumeClaim(PVC)
    • 1.3.3 PV和PVC的关系和图解
• 2. PersistentVolume(PV)的分类
  • 2.1 静态PV
  • 2.2 动态PV
• 3. PersistentVolumeClaim(PVC)的保护
• 4. PersistentVolume(PV)支持的底层存储类型
• 5. PersistentVolume(PV)的资源清单
  • 5.1 资源清单示例
  • 5.2 PV的访问模式(spec.accessModes)
    • 5.2.1 三种访问模式
    • 5.2.2 各种底层存储具体支持的访问模式
  • 5.3 PV的回收策略(spec.persistentVolumeReclaimPolicy)
    • 5.3.1 回收策略的三种策略
    • 5.3.2 回收策略注意事项
• 6. PersistentVolume(PV)的状态
• 7. 实验-持久化演示说明-NFS
  • 7.1 安装NFS服务器
  • 7.2 在其他节点上安装客户端
  • 7.3 部署PV
  • 7.4 创建服务并使用PVC
• 8. 关于 Statefulset

1. PersistentVolume(PV)简介#

1.1 为什么需要Persistent Volume(PV)#

在讲PersistentVolume(PV)之前，我们需要先讲一下Volume

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

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

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

---

1.2 PersistentVolume(PV)和Volume的区别#

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

1. PV只能是网络存储，不属于任何Node，但是可以在每个Node上访问
2. 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中选取一个匹配度最高的pv

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

---

2. PersistentVolume(PV)的分类#

2.1 静态PV#

简单来说

由集群管理员手动创建的一些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 资源清单示例#

Copy
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 回收策略注意事项#

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

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

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

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

---

6. PersistentVolume(PV)的状态#

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

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

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

---

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

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

7.1 安装NFS服务器#

Copy
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 在其他节点上安装客户端#

Copy
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#

Copy
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#

Copy
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#

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

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

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

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

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

比如上面的 volumeMounts.name=www,Podname-web-[0-2]，因此创建出来的PVC是 www-web-0、www-web-1、 www-web-2

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