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

1
2
3
4
5
6
7


volumeMounts:
  - mountPath: /var/www/nginx
    name: vol
    subPath: subdir1
  - mountPath: /config
    name: vol
    subPath: subdir2

特殊类型的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状态。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Mi
  dataSourceRef:
    apiGroup: hello.k8s.io
    kind: Hello
    name: example-hello
  volumeMode: Filesystem

用户需要额外实现一个卷填充控制器，该控制器实现调谐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

Kubernetes卷知识点

文章目录