在传统公有云上运行 Kubernetes 时，海量的基础设施编排工作被默认“隐形”了。云厂商通过一套干净、统一的 API，隐藏了虚拟机 provisioning、VPC 配置、软件定义网络流量路由、块存储挂载等全部复杂性。当你在 AWS 或 GCP 上部署一个 LoadBalancer 类型的 Service 时，Cloud Controller Manager（CCM）会与云厂商专有控制面通信，分配外部 IP、配置负载均衡器、更新路由表——这一切对用户完全透明。

然而在裸金属环境中，这种优雅的抽象轰然倒塌。过去，平台工程师要在裸金属上跑 Kubernetes，不得不将一堆互不相关的工具拼凑在一起：用 MetalLB 之类的 BGP 守护进程做 IP 分配，用 Tinkerbell 或 MaaS 做 PXE 启动基础设施，还要靠复杂的 CSI 驱动去协调物理 SAN。物理硬件的控制回路与 Kubernetes 编排引擎从根本上就是解耦的，由此产生了脆弱、难以调试的环境。

打开网易新闻 查看精彩图片

传统裸金属部署依赖的 IPMI/BMC 接口和 Redfish API 以缓慢、不安全、极易状态失同步而著称。当某个节点故障时，Kubernetes 控制面根本无法可靠判断该物理机是宕机、网络分区还是正在重启。由于缺乏单一事实来源，脑裂场景和故障切换延迟几乎无法避免。

Oxide Computer Company 的裸金属云基础设施方案，为化解这一摩擦提供了一个极具参考价值的案例。通过协同设计硬件、Hypervisor 与控制面，Oxide 引入了原生的 Kubernetes 集成，重新思考了裸金属网络、计算 provisioning 与存储控制回路之间的交互方式。

在本文中，我将分析这些集成背后的架构决策，重点聚焦于 Oxide 如何将网络控制面从 Cloud Controller Manager 中解耦出来——这一设计不仅让裸金属节点像云主机一样即插即用，更从根本上消除了物理层与编排层之间的状态分裂。对于正在裸金属上挣扎于脆弱工具链的团队而言，Oxide 的路径值得深入拆解。