OCI 规范建立的目的就是将容器镜像格式标准化，正如其名，OCI 镜像在之前一直用来跑容器，但现在它还能干更多事。
Kubernetes v1.36 里 ImageVolume 特性正式 GA 了，该特性允许我们把 OCI 镜像直接作为 Volume 挂载到 Pod 里。现在 OCI 镜像在 K8s 里不再只能跑容器了，模型权重、配置文件、安全签名、CI/CD 工件，只要是只读数据，都可以打包成 OCI 镜像供 Pod 挂载使用。
不知道你们有没有发现，进入 AI 时代之后，传统微服务那套 HPA 好像突然不好使了。
CPU 20%，内存 30%，监控面板一片岁月静好，但你的 AI 推理服务已经在排队了。HPA 看了一眼指标，嗯，一切正常，不用扩。
KubeClipper 发布了 1.6.0 版本：支持 Kubernetes 1.36，容器运行时从 Containerd 1.x 升级到 2.x，Calico 更新到 v3.31.5。kcctl 新增了 kcctl set cluster、kcctl operation 等命令，并优化了 Registry 管理体验，修复了大量稳定性问题。
KubeClipper 是一个轻量便捷的 Kubernetes 多集群全生命周期管理工具，旨在提供易使用、易运维、极轻量、生产级的 Kubernetes 多集群管理服务，让运维工程师从繁复的配置和晦涩的命令行中解放出来，实现一站式管理跨区域、跨基础设施的多 K8S 集群。
随着 Vibe Coding 的流行，开源社区也是涌现出了大量的 AI 编程工作流，例如： Superpowers、Everything Claude Code、Spec Kit、OpenSpec、gstack、Get Shit Done 等等。 今天给大家分享的是 OpenSpec + Superpowers 的协同工作流。
前三篇我们完成了 DRA 的部署实战、核心概念拆解和工作流程分析。但一直使用的是 NVIDIA 官方的 DRA Driver，如果我们的硬件不是 GPU，或者只是想暴露自定义资源给 Pod 使用，该怎么办？
本文从零实现一个自定义 DRA Driver —— i-dra-driver，沿用之前 Device Plugin 文章 中的 “gopher” 资源隐喻，将节点上的文件作为设备暴露给 Pod。通过对比同一个功能在 DevicePlugin 和 DRA 两种框架下的实现差异，加深对 DRA 机制的理解。
前两篇我们完成了 DRA 的部署实战和核心概念拆解，知道了 ResourceSlice、DeviceClass、ResourceClaim 各自的职责和协作方式。
但还有一个问题没回答：从 Pod 提交到 GPU 可用，中间到底发生了什么？每个组件具体做了哪些事？
本篇逐阶段拆解 DRA 的端到端工作流，每个阶段结合 NVIDIA DRA Driver 源码分析，然后深入调度器分配算法。
