在2024年底，客户和潜在客户渴望在Oxide上运行Kubernetes，但我们没有支持的集成来帮助他们实现这一目标。Kubernetes与Oxide是天然的结合。Kubernetes通过标准扩展点定义其期望的基础设施行为，而Oxide通过API暴露实现该行为所需的原语。集成的基础已经存在。缺失的是软件和对客户实际需要哪些集成的理解。这就是我以首席解决方案软件工程师身份加入Oxide时的情况，专注于构建软件以解决客户问题。我的第一项任务是更容易地在Oxide上部署和运行Kubernetes。在我的第一周，我被交给了两个资源来帮助我入手：一份客户提交的Rancher节点驱动程序的拉取请求和RFD 493初步Kubernetes集成的早期草稿。最初以这两个资源开始的工作，逐渐发展成一个受反馈循环驱动的团队合作。我们没有在抽象中设计集成，而是跟随客户在从配置集群到操作工作负载过程中遇到的问题。这篇文章跟随这些问题贯穿Kubernetes生命周期，而不是严格按时间顺序。不同的配置工作流使我们接触到Rancher、Omni和Cluster API。运行集群要求进行基础设施协调，暴露应用程序揭示了网络缺口，状态工作负载暴露了存储限制。在每个阶段，客户工作流揭示了下一个缺口，塑造了我们建设的集成及仍需进行的平台工作。我该如何在Oxide上配置Kubernetes集群？我们解决的第一个缺口是配置。我们的直接目标是解锁提交Rancher节点驱动程序拉取请求的客户。解决他们的用例也将让我们亲身体验在Oxide上创建Kubernetes集群，并帮助我们发现下一个需要解决的问题。没有单一的配置方法适合所有客户的工作流，因此我们最终发布了三个集成。Rancher节点驱动程序在我们能够维护客户提交的集成之前，需要理解它支持的工作流。我之前从未使用过Rancher或使用过节点驱动程序，因此审查这个贡献意味着要学习这两者。Rancher节点驱动程序是一个可执行插件，它教会Rancher如何在特定基础设施平台上创建和管理虚拟机。Oxide Rancher节点驱动程序将这些操作转换为Oxide API请求。安装在Rancher后，它允许客户将Oxide实例配置为Rancher管理的Kubernetes集群中的节点。测试证明客户的实现有效。我合并了拉取请求，添加了CI/CD和文档改进，并发布了初始版本。Oxide正式拥有了第一个Kubernetes集成——而且客户已经在生产环境中成功使用它！如果您是一个希望在Oxide上运行Kubernetes的Rancher商店，请查看我们的Rancher指南以开始。Omni基础设施提供者客户表达了使用Sidero Labs的Omni来配置运行Talos Linux的Kubernetes集群的兴趣。Omni通过基础设施提供者连接到基础设施平台，基础设施提供者是创建Talos Linux实例并在Omni中注册它们的程序。在KubeCon北美2025即将到来之际，我们看到了与Sidero Labs合作的机会，建立并展示一个Oxide基础设施提供者供Omni使用。我们有七周的时间在Oxide+Sidero活动之前完成它。针对第二个配置平台的构建也将测试Oxide在不同客户工作流中的API。集成工作发现了Omni和Talos Linux之间的几个问题。我把这些问题带给Sidero Labs，在siderolabs/omni#1633的问题上，他们的团队渴望与我们合作——这是RFD 68“合作作为共享价值”的美好提醒。最令人难忘的问题是siderolabs/talos#11948。Oxide使用FAT12文件系统用于cloud-init用户数据，而不是ISO 9660，但Talos的文件系统探测仅尝试从NoCloud配置磁盘读取ISO 9660超级块。当该读取失败时，探测停止，而不是尝试其他格式，如VFAT或MS-DOS。因此，Talos从未读取包含加入Omni所需配置的Oxide用户数据。这个修复将在KubeCon之前不会发布，留下我们一个相当有趣的变通办法。目前的变通办法是用注释填充用户数据，以增加其大小到足以使用ISO 9660超级块。KubeCon来临，我们主办了一场Oxide+Sidero活动，以展示Oxide基础设施提供者给Omni。客户现在可以使用此基础设施提供者配置在Omni管理的Kubernetes集群中的运行Talos Linux的Oxide实例。如果您是一个希望在Oxide上运行Kubernetes的Omni或Talos Linux商店，请查看我们的Omni指南以开始。Cluster API提供者我们知道