2024年底，Oxide Computer这家做机架级私有云硬件的公司还没有一款官方支持的Kubernetes集成，客户已经自己动手，提交了一份Rancher node driver的PR。这不是产品经理规划出来的功能，是客户在生产环境里等不及了。Oxide后来把这段经历写成一篇长文回顾：过去一年里，公司陆续放出了Rancher、Omni、Cluster API三条集群供给路径，外加一个跑在集群内部的云控制器管理器（CCM）。核心判断很直接——这家公司的Kubernetes生态，是被客户倒逼出来的，不是照着内部规划表按部就班交付的。
客户先交卷，内部路线图后追认
Oxide内部的RFD 0493文档给出的路线图顺序是Cluster API在前，CCM居中，CSI存储垫后，CNI、Ingress、Gateway API这些则被明确推迟。但真实的交付顺序完全反着来：先是merge客户提交的Rancher驱动、补上CI/CD和文档；接着是为了赶KubeCon North America 2025，和Sidero Labs用七周时间合作做出Omni的Oxide infrastructure provider；Cluster API反而是最后落地的一个，直到团队扩员后才由内部工程师接手完成，如今CAPOx已经被写进了上游kubernetes-sigs/cluster-api的官方quick-start文档。
七周冲刺的过程里还闹出一个插曲：Talos Linux的文件系统探测只认ISO 9660格式，读不出Oxide用的FAT12格式cloud-init数据，配置文件形同虚设。修复来不及在KubeCon前上线，团队的临时方案是往user-data里塞注释，把文件撑大到超过阈值、逼系统走ISO 9660分支去读。这类细节看着滑稽，但说明一件事：客户需求出现的先后顺序，直接改写了工程优先级，纸面规划只是参考。
为什么重要：CCM打通了运行时，但CNI这块Oxide主动不接
三条供给路径解决的是"怎么把节点建出来"，真正让集群和Oxide硬件对上话的，是那个跑在集群内部的云控制器管理器（CCM）。它负责把Kubernetes的Node对象和Oxide实例状态同步——实例挂了、node要不要摘掉，全靠它判断；它还负责LoadBalancer类型Service，因为Oxide目前没有原生负载均衡，只能借浮动IP做转发，kubectl get service里会同时显示浮动IP和节点内网IP两个地址，这是个不完美但能用的折中方案。
- 结论.CCM给Oxide留了一个稳定的扩展口子，以后加新能力不用逐个改供给工具，只要往CCM里加控制器就行。
CNI这块，Oxide选择完全不碰，理由写得很干脆：Calico、Cilium、Flannel这些第三方方案已经足够成熟，没必要重复造轮子。这是一个清醒的取舍，但也意味着Oxide在Pod网络这一层没有差异化能力，客户还得自己去处理CNI和Oxide VPC、防火墙规则之间的对接细节。
最值得盯的短板：磁盘还不能带电拔插
三条腿走稳了，最后一块骨头是存储。Oxide把CSI插件单独拆成了一份RFD 0595，设计思路是通过oxide-disk这类StorageClass创建PVC，CSI controller调Oxide API去建、删磁盘。问题出在实现约束上：磁盘的挂载和卸载目前必须先停掉整台实例，这在Kubernetes的正常调度逻辑里是个麻烦——Pod从一个节点漂移到另一个节点，本该是无缝的，但如果背后的卷迁移要求先关机，重调度就会变成一次实打实的停机。
- 风险.CSI初版能不能落地，直接取决于Oxide底层是否补上磁盘热插拔支持，这是目前整套集成栈里最不成熟的一环。
RFD 0595里还提到了基于机架、cell故障域的拓扑感知卷调度，这本该是多机架部署下的标配能力，但因为Oxide的多机架拓扑模型本身还不成熟，这部分工作被直接推迟。存储，尤其是有状态负载，暴露的不只是一个功能缺口，更像是Oxide硬件控制平面还没走到的下一站。
客户需求出现的先后顺序，比任何一份内部路线图都更能预测优先级。
对已经用Oxide跑无状态负载的团队来说，三条供给路径加CCM已经够用，选Rancher还是Omni还是Cluster API，取决于自己原本的技术栈习惯。但如果打算在Oxide上跑数据库、消息队列这类有状态服务，现在还不是最佳时机——磁盘热插拔什么时候补上，才是真正决定这套集成栈能不能用于生产的那个变量。