kubernetes不支持blkio.weight配置，因其资源模型聚焦cpu/内存等标准指标，而blkio.weight是cgroup v1底层参数，依赖特定io调度器，且cgroup v2已改用io.weight，k8s未定义对应api字段，运行时也不透传该参数。
在 Kubernetes 中不能直接通过 Cgroup 参数（如 blkio.weight）限制 Pod 内容器的磁盘 IO 权重，因为 Kubernetes 原生不暴露或支持配置 cgroup v1 的 blkio.weight，也不在 Pod 或 Container 级别提供对应字段。
为什么 Kubernetes 不支持 blkio.weight 配置
Kubernetes 的资源模型聚焦于 CPU、内存等标准化指标，而磁盘 IO 权重（blkio.weight）属于 Linux cgroup v1 blkio 子系统的底层调度参数，依赖 CFQ/BFQ 等特定 IO 调度器，且：
- 仅在 cgroup v1 下有效，而现代系统（尤其是启用 systemd 的节点）默认使用 cgroup v2，其 IO 控制机制已改为
io.weight，语义和路径完全不同； - Kubernetes 没有定义
resources.limits/io.weight或类似 API 字段，kubelet 不解析或下发该参数； - Docker 和 containerd 运行时均不将
--blkio-weight映射为容器运行时选项，K8s 无法透传。
替代方案：用 RuntimeClass + 自定义 OCI Hook（有限可行）
若确需在 K8s 中实现类似效果，唯一可行路径是绕过原生 API，借助运行时扩展能力：
- 使用
RuntimeClass绑定定制 containerd 配置，配合 OCI runtime hook（如oci-set-blkio-weight）； - hook 在容器创建时，根据标签（如
io-weight: 800）自动写入/sys/fs/cgroup/blkio/<cgroup-path>/blkio.weight</cgroup-path>（v1）或/sys/fs/cgroup/<cgroup-path>/io.weight</cgroup-path>（v2）； - 要求节点内核启用相应调度器（如
echo bfq > /sys/block/nvme0n1/queue/scheduler），且挂载 cgroup blkio 或 io 子系统。
⚠️ 注意：该方式非标准、不可移植、需深度运维介入，不适用于托管集群（如 EKS、AKS、GKE）。
生产环境更推荐的 IO 控制手段
与其硬控权重，不如从架构和资源隔离层面缓解 IO 抢占：
-
节点拓扑隔离：用
nodeSelector或TopologySpreadConstraints将高 IO 应用（如 MySQL）与普通服务部署在不同物理磁盘的节点上； - 存储类分级：为关键应用绑定高性能 StorageClass（如本地 SSD、NVMe），非关键日志类走 HDD 或网络存储；
-
容器层限速（bps/iops）：虽非权重，但可在 Pod 启动前注入
docker run --device-write-bps=/dev/nvme0n1:5m类参数（需自研 operator 或 initContainer 拦截）； -
监控驱动调优：用
iostat -x 1和cAdvisor指标识别 IO 热点，结合 HPA 或手动扩缩容分摊压力。
验证是否生效的关键检查点
若已通过 hook 或其他方式设置了权重，务必验证实际效果：
- 进节点查容器 cgroup 路径：
crictl inspect <pod-id> | grep cgroupPath</pod-id>； - v1 下读取：
cat /sys/fs/cgroup/blkio/<path>/blkio.weight</path>； - v2 下读取：
cat /sys/fs/cgroup/<path>/io.weight</path>； - 压测对比：用
fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k --iodepth=64 --runtime=60观察延迟和吞吐变化。
