作者：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 日
KubeCon + CloudNativeCon 和 Open Source Summit 赞助方案 KubeCon + CloudNativeCon 和 Open Source Summit 多元化奖学金现正接受申请 KubeCon + CloudNativeCon 和 Open Source Summit 即将首次合体落地中国 KubeCon + CloudNativeCon 和 Open Source Summit 购票窗口，立即购票！