意琦行的个人博客

不知道你们有没有发现，进入 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 源码分析，然后深入调度器分配算法。

RTK (Rust Token Killer) 是一个 CLI 代理工具，它的核心思路是在命令输出到达 AI 之前把噪音过滤压缩掉，从而实现平均省 60-90% 的 token 的效果。