k8s存储卷与数据持久化(9)
时间:2020-09-23 15:52 来源:未知 作者:liangzh 点击:次
|
OpenStack 构建的 IaaS 环境中时， Cinder 的块存储功能可为 Pod 资源提供外部持久存储的
有效方式
Pod资源上定义使用 Cinder存储卷时,可用的嵌套字段包含如下几个
volumeID <string> ：用于标识 inder 中的存储卷的卷标识符，必选字段
readOnly <boolean>: 是否以只读方式访问
fsType 要挂载的存储卷的文件系统类型，至少应该是节点操作系统支持的文件系
统，如 ext4 xfs ntfs 默认为ext4
下面的资源清单是定义在 vol-cinder.yaml文件中的使用示例，假设在 OpenStack 环境中
有创建好的 inder 卷“ e2b8d2 wece-90dl-a505-4acf607a90bc ”可用：
apiVersion : vl
kind : Pod
metadata :
name: vol-cinder-pod
spec:
containers
- image : mysql
name : mysql
args :
- ” - ignore-db-dir”
-”lost+found ”
env :
- name : MYSQL_ROOT_ PASSWORD
value : YOUR_PASS
ports
- containerPort : 3306
name: mysqlport
volumeMounts:
- name : mysqldata
mountPath : /var/lib/mysql
volumes :
- name : mysqldata
cinder
volumeID : e2b8d2f7 wece 90dl-a505-4acf607a90bc
fsType : ext4
配置可用的系统环境和存储资源时，将其匹配于资源清单文件中即可完成 Pod 资源创
另外， Kubernetes 持的各类持久存储卷其配 使用方式各有不同， 于篇幅有限，
这里不再一一列举其使用方式
5> 持久存储卷
通过前面使用持久存储卷（ Persi stent Volume ）的示例可知， Kubernetes 用户必须要清
晰了解所用到的网络存储系统的访问细节才能完成存储卷相关的配置任务，例如， NFS
储卷的 server path 字段的配置就依赖于服务器地址和共享目录路径 这与 Kubernetes
向用户和开发隐藏底层架构的目标有所背离，对存储资源的使用最好也能像使用计算资源一
样，用户和开发人员无须了解 Pod 资源究竟运行于哪个节点，也无须了解存储系统是什么
设备以及位于何处 为此， Kubernetes PersistentVolume 子系统在用户与管理员之间添加
个抽象层，从而使得存储系统的使用和管理职能互相解耦。
PersistentVolume ( PV ）是指由集群管理员配置提供的某存储系统上的一段存储空间，
它是对底层共享存储的抽象，将共享存储作为一种可由用户申请使用的资源，实现了“存储
消费”机制。通过存储插件机制， PV支持使用多种网络存储系统或云端存储等多种后端存
储系统，例如，前面使用的 NFS 、RBD、Cinder等。PV是集群级别的资源，不属于任何
名称空间，用户对 PV 资源的使用需要通过 PersistentVolumeClaim (PVC ）提出的使用申请
（或称为声明）来完成绑定，是 PV 资源的消费者，它向 PV 申请特定大小的空间及访问模式
（如 rw ro ），从而创建出 PVC 存储卷，而后再由 Pod 资源通过 PersistentVolumeClaim 存储
卷关联使用。
尽管 PVC 使得用户可以以抽象的方式访问存储资源，但很多时候还是会涉及 PV
不少属性，例如，用于不同场景时设置的性能参数等 为此，集群管理员不得不通过多
种方式提供多种不同的 PV 以满足用户不同的使用需求，两者衔接上的偏差必然会导致用
户的需求无法全部及时有效地得到满足。Kubernetes1.4 版起引入了一个新的资源对象
StorageClass ，可用于将存储资源定义为具有显著特性的类别（ Class ）而不是具体的 PV ，例
如"fast"，"slow"或"glod"，"silver ，"bronze"等 用户通过 PVC 直接向意向的类别发出
申请，匹配由管理员事先创建的 PV ，或者由其按需为用户动态创建 PV ，这样做甚至免去
了需要事先创建 PV 的过程。
PV 对存储系统的支持可通过 插件来实现，目前， Kubernetes 支持如下类型的插件
GCEP rsistentDisk
AzureFile (责任编辑：liangzh) |