kubernetes 不直接支持 docker 的 --device-read-iops 参数，因其属 docker cli 特有且依赖 cgroup v1，而 kubelet 和 containerd 未将其暴露为 api 字段；可通过 runtimeclass + oci hook 注入 device-read-bps、存储分层隔离或应用层限流间接实现 iops 控制。
Kubernetes 本身不直接支持 Docker 的 --device-read-iops 这类参数，因为该参数是 Docker CLI 特有的、面向 cgroup v1 blkio 子系统的命令行接口，而 Kubernetes 的容器运行时抽象（如 containerd）默认不透传这类底层块设备级 IOPS 限制。
但你仍可在 Kubernetes 中间接实现容器磁盘读取 IOPS 上限控制，核心思路是：绕过 Kubernetes 原生字段，通过 runtimeClass + 自定义 OCI 配置 或 直接使用特权级 init 容器+宿主机 cgroup 操作来达成。不过更现实、稳定且被广泛采用的方式是——改用带宽（bps）限制 + 应用层/存储层协同设计。下面分三类路径说明：
明确不支持的原生方式
Kubernetes 的 Pod resource limits（如 resources.limits.ephemeral-storage）只管容量，不管 IOPS 或吞吐；device-read-iops 无法写在 securityContext 或 resources 字段中，docker run --device-read-iops 的能力在 kubelet 和 containerd 当前主流版本中未暴露为 API 字段。
推荐方案：用 device-read-bps 替代，并映射为等效 IOPS
对随机读场景（如数据库），IOPS 和带宽存在经验换算关系。例如：
- 4KB 随机读 × 1000 IOPS ≈ 4MB/s（即
--device-read-bps=/dev/nvme0n1:4m） - 16KB 混合读 × 500 IOPS ≈ 8MB/s
你可在 DaemonSet 或节点级初始化中确认目标设备路径（如 lsblk -o NAME,ROTA,TYPE,MOUNTPOINT），然后在 Pod 的 runtimeClassName 对应的 RuntimeClass 配置中，通过 containerd 的 config.toml 启用 OCI hooks 或 custom runc 配置，注入类似以下的 --device-read-bps 效果：
# 在 containerd config.toml 中启用 OCI hook（需提前部署） [plugins."io.containerd.runtime.v1.linux".hooks.prestart] path = "/opt/bin/blkio-limit-hook"
该 hook 脚本可在容器启动前，根据 Pod Annotation（如 io.kubernetes.blkio/read-iops: "2000"）自动计算并写入 /sys/fs/cgroup/blkio/kubepods.slice/.../blkio.io_service_bytes_recursive 或 blkio.weight_device。
更可行的生产实践：分层控制 + 存储分离
与其强求单容器 IOPS 精确上限，不如从架构上规避争抢：
-
物理隔离：将高 IOPS 容器（如 PostgreSQL）调度到挂载 NVMe 的专用节点，低优先级日志类容器调度到 SATA 节点（用
nodeSelector+topologyKey） -
存储类分级：为不同负载创建
StorageClass，绑定不同 QoS 的后端（如 Ceph RBD profile、AWS gp3 with iopsPerGB） -
应用侧限流：数据库内设
random_page_cost、连接池大小、预读缓冲区；日志采集器（Fluentd/Filebeat）开启flush_interval和buffer_limit -
配合节点级 cgroup 控制：在 kubelet 启动参数中加
--systemd-cgroup=true，再通过systemd-run --scope -p IOWeight=500启动关键 Pod（需自定义 kubelet wrapper）
验证是否生效
进 Pod 执行：
dd if=/dev/urandom of=/tmp/test bs=4k count=10000 oflag=direct
同时在宿主机查：
cat /sys/fs/cgroup/blkio/kubepods.slice/kubepods-burstable-pod<id>.scope/blkio.io_service_bytes | grep Read</id>
若 Throttled 类统计持续增长，说明限速已触发。
本质上，Kubernetes 当前生态对细粒度磁盘 IOPS 的管控仍是“弱支持”，真正落地要靠运行时扩展 + 存储架构优化 + 应用适配三者结合。
