深刻玩转K8S之存储资源管理

本篇咱们来看下K8S中的存储资源管理,说到K8S的存储资源管理分为几个概念:Vloume、PV、PVC等,本篇咱们主要侧重于PV和PVC。html

 

下面简单说下几个概念:web

Volume 的生命周期独立于容器,Pod 中的容器可能被销毁和重建,但 Volume 会被保留。Kubernetes Volume 实际上就是一个目录,这一点与 Docker Volume 相似。当 Volume 被 mount 到 Pod,Pod 中的全部容器均可以访问这个 Volume。Kubernetes Volume 也支持多种 backend 类型,包括 emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph 等,完整列表可参考 https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes安全

 

Volume 提供了很是好的数据持久化方案,不过在可管理性上还有不足。bash

拿前面 AWS EBS 的例子来讲,要使用 Volume,Pod 必须事先知道以下信息:服务器

1.     当前 Volume 来自 AWS EBS。app

2.     EBS Volume 已经提早建立,而且知道确切的 volume-id。ide

 

Pod 一般是由应用的开发人员维护,而 Volume 则一般是由存储系统的管理员维护。开发人员要得到上面的信息:spa

1.     要么询问管理员。rest

2.     要么本身就是管理员。orm

 

这样就带来一个管理上的问题:应用开发人员和系统管理员的职责耦合在一块儿了。若是系统规模较小或者对于开发环境这样的状况还能够接受。但当集群规模变大,特别是对于生成环境,考虑到效率和安全性,这就成了必需要解决的问题。


Kubernetes 给出的解决方案是 PersistentVolume 和 PersistentVolumeClaim。

 

PersistentVolume (PV) 是外部存储系统中的一块存储空间,由管理员建立和维护。与 Volume 同样,PV 具备持久性,生命周期独立于 Pod。

PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 一般由普通用户建立和维护。须要为 Pod 分配存储资源时,用户能够建立一个 PVC,指明存储资源的容量大小和访问模式(好比只读)等信息,Kubernetes 会查找并提供知足条件的 PV。

 

有了 PersistentVolumeClaim,用户只须要告诉 Kubernetes 须要什么样的存储资源,而没必要关心真正的空间从哪里分配,如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理,只有管理员才应该关心建立 PersistentVolume 的细节信息。

 

Kubernetes 支持多种类型的 PersistentVolume,好比 AWS EBS、Ceph、NFS 等,完整列表请参考 https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes


下面咱们用 NFS 来看下PersistentVolume 的使用方法。

 

首先在各个节点安装nfs-utils以及rpcbind,否则后续会报错。

yum install –y nfs-utils rpcbind

 

安装完以后设置共享目录以及权限。

vi /etc/exports
/mnt * (rw,no_root_squash,no_all_squash,sync)
 
systemctl restart nfs

systemctl restart rpcbind

完事以后重启nfs和各节点的rpcbind服务,使用showmount –e来检查是否成功。

 

下面建立一个 PV mypv1,配置文件 nfs-pv1.yml 以下:

博客01.png

kubectl apply -f nfs-pv1.yml

文件解释:

① capacity 指定 PV 的容量为 1G。

② accessModes 指定访问模式为 ReadWriteOnce,支持的访问模式有:
ReadWriteOnce – PV 能以 read-write 模式 mount 到单个节点。
ReadOnlyMany – PV 能以 read-only 模式 mount 到多个节点。
ReadWriteMany – PV 能以 read-write 模式 mount 到多个节点。

③ persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle,支持的策略有:
Retain – 须要管理员手工回收。
Recycle – 清除 PV 中的数据,效果至关于执行 rm -rf /thevolume/*。
Delete – 删除 Storage Provider 上的对应存储资源,例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

④ storageClassName 指定 PV 的 class 为 nfs。至关于为 PV 设置了一个分类,PVC 能够指定 class 申请相应 class 的 PV。

指定 PV 在 NFS 服务器上对应的目录。

 

接下来建立 PVC mypvc1,配置文件 nfs-pvc1.yml 以下:

博客02.png

kubectl apply -f nfs-pvc.yml

PVC 就很简单了,只须要指定 PV 的容量,访问模式和 class。

 

从 kubectl get pvc 和 kubectl get pv 的输出能够看到 mypvc1 已经 Bound 到 mypv1,申请成功。

博客03.png

 

接下来就能够在 Pod 中使用存储了,Pod 配置文件 pod1.yml 以下:

博客04.png

kubectl apply -f pod1.yml


博客05.png

 

下面来验证下PV是否可用:

 

博客06.png

 

OK,到这里本章就结束了,能够看到,在 Pod 中建立的文件 /mydata/devin 已经保存到了 NFS 服务器目录 /mnt/k8s/pv1 中。


本文参考连接:

https://blog.51cto.com/goome/2133827

https://www.cnblogs.com/DaweiJ/articles/8618317.html

相关文章
相关标签/搜索