Kubernetes卷知识点
文章目录
Kubernetes关于存储卷中一些比较容易忽略的特性
Volume
HostPath Volume 的类型
hostPath支持type字段,允许Pod挂载地址时对文件或者目录进行类型检查:
值 | 说明 |
---|---|
空字符串 | 默认配置,不进行检查 |
DirectoryOrCreate | 如果在给定路径上什么都不存在,那么将根据需要创建空目录,权限设置为 0755,具有与 kubelet 相同的组和属主信息。 |
Directory | 在给定路径上必须存在的目录。 |
FileOrCreate | 如果在给定路径上什么都不存在,那么将在那里根据需要创建空文件,权限设置为 0644,具有与 kubelet 相同的组和所有权。 |
File | 在给定路径上必须存在的文件。 |
Socket | 在给定路径上必须存在的 UNIX 套接字。 |
CharDevice | 在给定路径上必须存在的字符设备。 |
BlockDevice | 在给定路径上必须存在的块设备。 |
说明:https://kubernetes.io/zh/docs/concepts/storage/volumes/#hostpath
emptyDir挂载内存磁盘
可以将 emptyDir.medium 字段设置为 “Memory”,以告诉 Kubernetes 挂载 tmpfs(基于 RAM 的文件系统)。 tmpfs 在节点重启时会被清除,并且写入的所有文件都会计入容器的内存消耗,受容器内存限制约束。
说明: 当启用 SizeMemoryBackedVolumes 特性门控时, 你可以为基于内存提供的卷指定大小。 如果未指定大小,则基于内存的卷的大小为 Linux 主机上内存的 50%。
SubPath参数
指定Container的volumeMounts参数时,用户可以指定SubPath参数,
下面定义中,假设vol对应的Volume为本机目录/data,该目录下有子目录 /data/subdir1 和 /data/subdir2,用户通过subpath参数可以将子目录挂载到容器的不通位置 同理当vol为configmap或者secret时,subPath的值可以理解为其中对应的Key
|
|
特殊类型的Volume
原生Kubernetes除了常用的HostPath、configMap、emptyDir还有其他特殊类型的Volume:
- DownwardAPIVolumeFile:用于Pod的自身的信息注入到Pod的容器中
说明:https://kubernetes.io/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/
- cephfs
说明:https://github.com/kubernetes/examples/tree/master/volumes/cephfs/
- rbd
说明:https://github.com/kubernetes/examples/tree/master/volumes/rbd
- iscsi
说明:https://github.com/kubernetes/examples/tree/master/volumes/iscsi
- glusterfs:
说明:https://github.com/kubernetes/examples/tree/master/volumes/glusterfs
- nfs
说明:https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs
- vsphere相关的数据挂载以及迁移:
说明: https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere
持久卷
volumeModes
Kubernetes支持以下两种volumeModes:
值 | 说明 |
---|---|
Filesystem(默认) | 卷可以被Kubernetes自动Mount到Pod的某个目录。如果卷的存储来自某块设备而该设备目前为空,Kuberneretes 会在第一次挂载卷之前 在设备上创建文件系统。 |
Block | 卷以块设备的方式交给 Pod 使用,其上没有任何文件系统,Pod内部逻辑需要如何处理原始块设备。 |
accessModes
Kubernetes支持以下四种访问模式(accessModes):
- ReadWriteOnce:允许一个Node的Pod同时读写卷
- ReadOnlyMany:允许多个Node的Pod同时读卷
- ReadWriteMany:允许多个Node的Pod同时读写卷
- ReadWriteOncePod(v1.22):只允许单个Pod读写卷
说明:https://kubernetes.io/blog/2021/09/13/read-write-once-pod-access-mode-alpha/
当容器使用持久卷时,K8S中的卷控制器会根据accessModes的模式限制卷的挂载和卸载行为。在宕机场景下,ReadWriteOnce和ReadWriteOncePod模式可能会导致Pod新副本的创建阻塞。
卷填充器
Kubernetes 支持自定义的卷填充器;Kubernetes 1.18 版本引入了这个 alpha 特性。 Kubernetes 1.22 使用重新设计的 API 重新实现了该机制。
说明:要使用自定义的卷填充器,你必须为 kube-apiserver 和 kube-controller-manager 启用 AnyVolumeDataSource 特性门控。–feature-gates=AnyVolumeDataSource=true
PVC的dataSourceRef指定了某个CRD对象后,Kubernetes不会将PVC交由指定的CSI处理,而是将PVC保持UnBound状态。
|
|
用户需要额外实现一个卷填充控制器,该控制器实现调谐PVC,实现以下逻辑:
- 判断dataSourceRef中的CRD对象是否是本控制器控制的
- 根据OriginPVC创建参数完全一致的PrimePVC(不带dataSourceRef参数)
- 创建工作POD并挂载PrimePVC,Kubernetes没有拦截PrimePVC,CSI自动创建了对应PV
- 工作POD将数据填充到PrimePVC中,并推出
- 控制器回收PrimePVC并查询其绑定的PV,将PV和PrimePVC解绑
- 绑定OriginPVC和PV
- 清理PrimePVC和工作POD
本质绝大部分逻辑用户需要在自定义的填充控制器中完成,Kubernetes只是在调用CSI之前,为用户提供了一个HOOK入口。
参考:https://kubernetes.io/blog/2021/08/30/volume-populators-redesigned/
kubernetes官方提供一个简单的卷填充器样例:https://github.com/kubernetes-csi/lib-volume-populator
文章作者 yoaz
上次更新 2021-11-11
许可协议 MIT