不能直接用bindmount挂载块设备提升数据库i/o性能，因其仅支持文件或目录；真正可行方案是--device透传+--cap-add=sys_admin+手动挂载裸盘并配置o_direct。
容器直接消费外部存储网关提供的物理块设备，核心在于让容器运行时（如 kata containers、openshift container storage 或基于 ceph rbd 的环境）绕过传统文件系统挂载路径，将远程块设备以“裸设备”方式透传给容器内部。这要求存储网关暴露标准块协议（如 iscsi、nvme-of 或 rbd 映射），且容器运行时支持设备直通或内核级块设备挂载。
确认存储网关支持的块协议类型
外部存储网关（如 Ceph RGW + RBD、OpenShift Data Foundation 的 Multicloud Object Gateway + Block Backend、或第三方 iSCSI 网关）需明确提供块设备能力，而非仅对象（Blob）或文件（NFS/SMB）服务：
- iSCSI 网关：需导出可发现的目标（Target），容器宿主机需安装 iscsi-initiator-utils 并执行 iscsiadm 发起连接，登录后生成 /dev/sdX 设备节点；
- Ceph RBD 网关：需启用 RBD kernel client 或 rbd-nbd 模式，通过 rbd map 将镜像映射为本地块设备（如 /dev/rbd0）；
- NVMe-oF 子系统：需配置 NVMe target（如 nvmetcli），容器宿主机用 nvme connect 建立连接，生成 /dev/nvmeXnY 设备；
- 不推荐使用仅支持 S3/Blob 接口的网关——它们无法提供块语义，必须经由 CSI 驱动转换为 PV/PVC，不属于“直接消费物理块设备”范畴。
在容器运行时中挂载块设备
挂载方式取决于容器平台是否允许特权访问宿主机设备：
-
Kata Containers：需在 runtime 配置中启用 block device passthrough，例如在 configuration.toml 中设置：
[hypervisor.qemu]<br>block_device_driver = "virtio-scsi"
再通过kata-runtime run --device /dev/rbd0:/dev/xvdb:rwm将映射后的设备传递给容器； -
OpenShift / Kubernetes + CSI：若追求“直接”，应避免走 CSI 动态卷流程（它抽象了底层），改用 hostPath + privileged pod 方式：
在 Pod spec 中指定securityContext.privileged: true，并添加volumeMounts挂载宿主机上的/dev/rbd0到容器内路径（如/dev/disk/by-id/rbd-xxx）； -
裸机容器（如 Podman rootful）：可直接使用
--device /dev/rbd0:/dev/xvdb启动容器，无需额外驱动，但需确保 udev 规则已同步设备权限。
验证设备可用性与权限
容器启动后，需确认设备被正确识别且可操作：
- 进入容器执行
lsblk或cat /proc/partitions，检查目标设备（如 xvdb、rbd0）是否存在； - 尝试读取设备头：
dd if=/dev/xvdb bs=512 count=1 | hexdump -C，非空输出说明设备可访问； - 若需格式化或挂载，确保容器内有对应工具（e2fsprogs、xfsprogs）且内核支持目标文件系统；
- 注意 SELinux/AppArmor 策略可能阻止对
/dev下设备的访问，必要时临时调整策略或使用container_runtime: unconfined（仅限测试）。
典型场景注意事项
不同后端网关对接时的关键差异点：
-
Ceph RBD：建议使用
rbd map --id admin --keyring /etc/ceph/ceph.client.admin.keyring poolname/imagename映射，避免依赖用户态 nbd（性能较低）； - iSCSI：务必在宿主机配置 multipath（多路径）以提升可用性，否则单路径断连会导致容器 I/O 挂起；
-
热插拔支持：Kata/QEMU 默认不支持运行时热插拔块设备，需提前在配置中开启
hotplug_vfio_on_root_bus = true并使用 SCSI 总线； - 数据一致性：块设备直通意味着容器与网关间无缓存层，应用需自行处理崩溃一致性（如使用 XFS + barrier、ext4 + journal）。
