Kubernetes v1.13对原始块卷支持转移到beta

作者：Ben Swartzlander（NetApp），Saad Ali（谷歌）

Kubernetes v1.13将原始块卷（raw block volume）支持转移到beta。此功能允许持久卷（persistent volume）作为块设备（block device），而不是作为已安装的文件系统在容器内部公开。

什么是块设备？

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

持久存储通常以分层方式实现，在块设备（如旋转磁盘或SSD）之上使用文件系统（如ext4）。然后，应用程序读取和写入文件，而不是在块上操作。操作系统负责使用指定的文件系统，将文件作为块读取和写入底层设备。

值得注意的是，整个磁盘都是块设备，磁盘分区也是，存储区域网络（SAN）设备的LUN也是。

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

有些专门的应用程序需要直接访问块设备，例如，文件系统层会引入不必要的开销。最常见的情况是数据库，它们更喜欢直接在底层存储上组织数据。原始块设备也常用于任何本身实现某种存储服务的软件（软件定义的存储系统）。

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

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

哪个卷插件支持原始块？

在发布此博客时，以下树内（in-tree）卷类型支持原始块：

• AWS EBS
• Azure Disk
• Cinder
• Fibre Channel
• GCE PD
• iSCSI
• Local volumes
• RBD (Ceph)
• Vsphere

树外（Out-of-tree） CSI卷驱动程序 也可以支持原始块卷。 Kubernetes CSI对原始块卷的支持目前是alpha。请参阅 此处 的文档。

Kubernetes原始块卷API

原始块与普通卷有很多共同点。两者都是通过创建绑定到PersistentVolume对象的PersistentVolumeClaim对象来请求的，并通过将它们包含在PodSpec的volumes数组中而附加到Kubernetes中的Pod。

但是有两个重要的区别。首先，要请求原始块PersistentVolumeClaim，必须在PersistentVolumeClaimSpec中设置volumeMode =“Block”。将volumeMode留空与指定volumeMode =“Filesystem”相同，这会导致传统行为。PersistentVolumes在其PersistentVolumeSpec中也有一个volumeMode字段，而“Block”类型的PVC只能绑定到“Block”类型的PV，而“Filesystem”PVC只能绑定到“Filesystem”PV。

其次，在Pods中使用原始块卷时，必须在PodSpec的Container部分而不是VolumeMount中指定VolumeDevice。VolumeDevices具有devicePaths而不是mountPaths，并且在容器内部，应用程序将在该路径中看到设备而不是已安装的文件系统。

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

创建新的原始块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规范 详细说明了如何处理具有BlockVolume功能而不是MountVolume功能的卷请求。CSI插件可以支持这两种卷。有关更多详细信息，请参阅 此处 。

问题/陷阱

因为块设备实际上是设备，所以可以从容器内部对它们执行低级操作，这是文件系统卷无法实现的。例如，实际上是SCSI磁盘的块设备支持使用Linux ioctls向设备发送SCSI命令。

默认情况下，Linux不允许容器将SCSI命令从容器内部发送到磁盘。为此，你必须将SYS_RAWIO功能授予容器安全上下文（context）以允许此操作。请参 阅此 处的文档。

此外，虽然Kubernetes保证向容器提供块设备，但不能保证它实际上是SCSI磁盘或任何其他类型的磁盘。用户必须确保所需的磁盘类型与其pod一起使用，或者仅部署可处理各种块设备类型的应用程序。

怎样能了解更多？

在 此处 查看有关快照功能的其他文档。

我如何参与？

加入Kubernetes 存储SIG 和 CSI社区 ，帮助我们添加更多优秀功能，并改进现有功能如原始块存储！

鸣谢

特别感谢帮助Kubernetes增加块卷支持的所有贡献者，包括：

• Ben Swartzlander（ https://github.com/bswartz ）
• Brad Childs（ https://github.com/childsb ）
• Erin Boyd（ https://github.com/erinboyd ）
• Masaki Kimura（ https://github.com/mkimuram ）
• Matthew Wong（ https://github.com/wongma7 ）
• Michelle Au（ https://github.com/msau42 ）
• Mitsuhiro Tanino（ https://github.com/mtanino ）
• Saad Ali（ https://github.com/saad-ali ）

KubeCon + CloudNativeCon和Open Source Summit大会日期：

• 会议日程通告日期：2019 年 4 月 10 日
• 会议活动举办日期：2019 年 6 月 24 至 26 日