Oxide 详述三条 Kubernetes 路径，原生存储仍未完成

Why it matters

Kubernetes is testing Oxide's central thesis: owning the full rack lets it fix customer problems across APIs, networking, storage and the hypervisor, while making Oxide responsible for every missing capability.

Oxide，这家由 Steve Tuck 和 Bryan Cantrill 创立的本地云硬件制造商，周四详述了客户需求如何推动其从 2024 年末没有任何受支持的 Kubernetes 集成，到现在维护三条配置路径和一个共享运行时控制器的过程。

8 月 13 日的技术说明 还不寻常地直接列出了剩余工作的清单。Oxide 仍然缺乏原生负载均衡服务，且原生 Kubernetes 存储驱动被 Cloud Computer 无法在实例运行时附加或卸载磁盘的限制所阻挡。

这些约束使 Kubernetes 的工作成为创始人最初押注的试金石。Tuck 和 Cantrill 围绕这样一个理念构建了 Oxide：本地基础设施应以集成的 cloud computer 形式交付，硬件、存储、网络和控制软件共同设计。Kubernetes 正在迫使该集成堆栈满足开发者期望的与公共云提供商相同的基础设施契约。

Matthew Sanabria 加入 Oxide 成为其首位 Solutions Software Engineer，他一直在把这项工作跨越客户与产品之间的边界推动。其第一个任务始于客户提交的 pull request 和一份 内部路线图，RFD 493。最终它产出了对 Rancher、Sidero Labs 的 Omni 与 Kubernetes Cluster API 的集成，以及在这些配置系统间共享的云控制器管理器。

客户代码成为路线图

第一个集成来自 Oxide 之外。一位客户提交了一个 Rancher 节点驱动的 pull request，将 Rancher 的配置操作转译为 Oxide API 调用。Sanabria 测试了该实现、合并了代码、添加了 CI/CD 和文档，并发布了初始版本。

Sanabria 表示该客户已在生产环境中运行该驱动。Oxide 并未公布该客户的身份、集群规模或工作负载特征，因此生产运行的说法仍属于厂商说明，而非独立测量的部署。不过该贡献仍然为 Oxide 提供了一个具体的起点：围绕真实运维者的工作流编写的软件，而不是一份推测性的集成计划。

这一模式在与 Sidero Labs 的 Omni 集成 中得以延续。客户希望在 Oxide 上配置 Talos Linux 机器并将其注册到 Omni。Oxide 于 2025 年 9 月 24 日开始了这项工作，给 Sanabria 的团队在 11 月 12 日 Oxide 与 Sidero 的活动前留出 七周 的时间。

这一节点暴露了一个低级别的兼容性错误。Oxide 使用 FAT12 文件系统呈现 cloud-init 用户数据，而 Talos 最初寻找的是 ISO 9660 超级块，并在该尝试失败后停止了探测。因此 Talos 无法读取加入 Omni 所需的配置。

临时修复体现了项目的务实本质：在用户数据文件中填充注释，使其变得足够大以符合 ISO 9660。Sidero 负责对底层问题进行修正，而 Oxide 使用该变通方法以保持在 11 月演示时的集成进度。

随后，Oxide 在客户需求和 Solutions Software Engineering 团队规模赶上工程成本后发布了 Cluster API Provider Oxide，即 CAPOx。CAPOx 允许运维人员使用 Kubernetes 自定义资源在 Oxide 机架上创建、扩展、升级和删除集群。它提供了一条不依赖 Rancher 或 Omni 作为管理层的 Kubernetes 原生路径。

这三种集成满足了不同运维者的偏好。Rancher 适合现有 Rancher 环境。Omni 将 Talos Linux 与 Sidero 的生命周期工具结合起来。CAPOx 让运维者通过 upstream Cluster API 模型管理集群基础设施。Oxide 当前的 Kubernetes 文档 推荐 Rancher 或 Omni 作为其最完整的托管配置选项，而 CAPOx 则为工程团队提供了另一个端到端系统以对自身基础设施进行测试。

Kubernetes 暴露了平台缺口

配置虚拟机只解决了运行 Kubernetes 的第一部分。一旦集群激活，Kubernetes 需要对其下方的基础设施有可靠的视图。Oxide 构建了开源的 cloud controller manager，用于调和 Kubernetes 的 Node 对象与 Oxide 实例，并上报告址、实例标识符和机器状态等细节。

该控制器还处理类型为 LoadBalancer 的 Kubernetes 服务，尽管 Oxide 还未交付原生的负载均衡服务。Oxide 使用浮动 IP 地址作为临时机制。控制器会将浮动 IP 附加到满足条件的 Kubernetes 节点，然后依赖集群的服务数据平面将流量路由到目标 Pod。

这种方法支持熟悉的 Kubernetes API，同时在其下方暴露了不完美的实现。用户在 Kubernetes 输出中既能看到对外可达的浮动 IP，也能看到节点的内部地址。根据 Oxide 的 cloud controller manager 文档，服务控制器会分配并将浮动 IP 附加到按名称排序的第一个节点。该控制器目前支持 externalTrafficPolicy: Cluster，这允许该节点将流量转发到集群中其它位置的 endpoints。

存储则提出了更难的约束。Kubernetes 期望 Container Storage Interface 驱动在 Pod 调度后创建并附加卷。Oxide 目前要求必须先停止实例，才能附加或卸载磁盘。为了一次卷操作而停止 Kubernetes worker 会中断其上的其他工作负载，并可能触发进一步的调度和存储变更。

因此，原生 Oxide CSI 插件依赖于 hypervisor、控制平面与 API 之间对磁盘热插拔的支持。Kubernetes 已将一个缺失的集成转化为一个遍及整套软硬件栈的平台需求。

创始人的整合押注在生产中接受考验

Oxide 的方法使 Tuck 和 Cantrill 能够控制解决这些问题所需的层级。同时，当标准云工作流触及机架尚不能提供的能力时，这也让 Oxide 承担起责任。Kubernetes 的工作已经在网络、存储、镜像构建和基础设施调和方面产生了项目，而不只是围绕 API 的一层薄薄的兼容性包装。

这种责任代价不菲。Oxide 在 2026 年 2 月 5 日 完成了 2 亿美元的 C 轮融资，此前在 2025 年 7 月完成了 1 亿美元的 B 轮融资。Oxide 表示 C 轮完全来自现有投资者；Intel Capital 表示 US Innovative Technology Fund 领投该轮。这笔融资为 Oxide 留出空间，在交付之后继续扩展资本密集型的实体产品，包括从客户的 Kubernetes 请求开始、并最终深入到 hypervisor 内部的平台工作。

Sanabria 的叙述展示了这些支出的运营模型。第一个 Rancher 代码由客户提供。Omni 的客户迫使 Oxide 与 Sidero 对文件系统假设进行调试。Cluster API 的需求证明了更大规模实现的合理性。有状态工作负载暴露了对磁盘热插拔的需求。

Oxide 现在拥有 Kubernetes 的配置和运行时集成，包括 Sanabria 所称至少已有一位客户在生产中使用的软件。原生 CSI 存储与原生负载均衡仍未完成。每一个未完成的部分都是对创始人承诺的又一次考验：拥有整个 cloud computer 是否能让本地基础设施表现得像云服务。