原始数据块卷支持Beta

作者: Ben Swartzlander(NetApp),Saad Ali(Google)

Kubernetes v1.13将原始块卷支持移至Beta。此功能允许将持久卷作为块设备而不是作为已安装的文件系统公开在容器内部。

什么是块设备?

块设备允许对固定大小的块中的数据进行随机访问。硬盘驱动器,SSD和CD-ROM驱动器都是块设备的示例。

通常,永久性存储是在块设备(例如旋转磁盘或SSD)顶部的文件系统(例如ext4)的分层方式中实现的。然后,应用程序读取和写入文件,而不是对块进行操作。操作系统负责使用指定的文件系统将文件作为块读和写到基础设备。

值得注意的是,虽然整个磁盘都是块设备,但磁盘分区也是如此,存储区域网络(SAN)设备中的LUN也是如此。

为什么要将原始块卷添加到kubernetes?

有些特殊的应用程序需要直接访问块设备,因为例如文件系统层会引入不必要的开销。最常见的情况是数据库,它更喜欢直接在基础存储上组织数据。原始块设备还通常由本身实现某种存储服务的任何软件(软件定义的存储系统)使用。

从程序员的角度来看,块设备是一个非常大的字节数组,通常具有一些最小的读写粒度,通常为512个字节,但通常为4K或更大。

随着在Kubernetes内部运行数据库软件和存储基础架构软件变得越来越普遍,在Kubernetes中对原始块设备支持的需求变得越来越重要。

哪些卷插件支持原始块?

在发布此博客时,以下树内卷类型支持原始块:

  • AWS EBS
  • Azure磁盘
  • 煤渣
  • 光纤通道
  • GCE PD
  • iSCSI
  • 本地卷
  • RBD(Ceph)
  • 球体

树外 CSI卷驱动程序 也可能支持原始块体积。 Kubernetes CSI对原始块卷的支持目前为alpha。查看文件 这里 .

Kubernetes原始块卷API

Raw block volumes share a lot in common with ordinary volumes. Both are requested by creating PersistentVolumeClaim objects which bind to PersistentVolume objects, and are attached to Pods in Kubernetes by including them in the volumes array of the PodSpec.

There are 2 important differences however. First, to request a raw block PersistentVolumeClaim, you must set volumeMode = "Block" in the PersistentVolumeClaimSpec. Leaving volumeMode blank is the same as specifying volumeMode = "Filesystem" which results in the traditional behavior. PersistentVolumes also have a volumeMode field in their PersistentVolumeSpec, and "Block" type PVCs can only bind to "Block" type PVs and "Filesystem" PVCs can only bind to "Filesystem" PVs.

Secondly, when using a raw block volume in your Pods, you must specify a VolumeDevice in the Container portion of the PodSpec rather than a VolumeMount. VolumeDevices have devicePaths instead of mountPaths, and inside the container, applications will see a device at that path instead of a mounted file system.

应用程序可以打开,读取和写入容器内的设备节点,就像它们在非容器化或虚拟化环境中与系统上的任何块设备进行交互一样。

创建一个新的原料块PVC

首先,请确保与您选择的存储类关联的配置程序支持原始块。然后创建PVC。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Block
  storageClassName: my-sc
  resources:
    requests:
    storage: 1Gi

使用原料块PVC

在Pod定义中使用PVC时,可以选择块设备的设备路径,而不是文件系统的安装路径。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: busybox
      command:
        - sleep
        - “3600”
      volumeDevices:
        - devicePath: /dev/block
          name: my-volume
      imagePullPolicy: IfNotPresent
  volumes:
    - name: my-volume
      persistentVolumeClaim:
        claimName: my-pvc

作为存储供应商,如何在CSI插件中添加对原始块设备的支持?

CSI插件的原始块支持仍为alpha,但是今天可以添加支持。的 CSI规范 details how to handle requests for volume that have the BlockVolume capability instead of the MountVolume capability. CSI plugins can support both kinds of volumes, or one or the other. For more details see 这里的文件.

问题/陷阱

由于块设备实际上是设备,因此可以从容器内部对其进行低级操作,而文件系统卷则无法执行这些操作。例如,实际上是SCSI磁盘的块设备支持使用Linux ioctl将SCSI命令发送到设备。

By default, Linux won’t allow containers to send SCSI commands to disks from inside containers though. In order to do so, you must grant the SYS_RAWIO capability to the container security context to allow this. See documentation 这里 .

另外,尽管Kubernetes保证可以将块设备交付到容器中,但不能保证它实际上是SCSI磁盘或任何其他类型的磁盘。用户必须确保所需的磁盘类型与他的Pod一起使用,或者仅部署可以处理各种块设备类型的应用程序。

我该如何学习?

在此处查看有关快照功能的其他文档: 原始块体积支持

我该如何参与?

加入Kubernetes存储SIG和CSI社区,帮助我们添加更多出色的功能并改进原始块存储等现有功能!

//github.com/kubernetes/community/tree/master/sig-storage //github.com/container-storage-interface/community/blob/master/README.md

特别感谢所有为Kubernetes增加区块量支持的贡献者,包括: