探索Oxide如何通过与Kubernetes的深度集成,解决客户在集群部署、运维和存储等关键环节的痛点,构建更高效的云原生生态系统。
在云原生技术日益成熟的今天,Kubernetes已成为容器编排的事实标准,而底层基础设施的选择则直接影响着集群的性能、成本与可维护性。Oxide作为一家专注于硬件与软件协同设计的现代化基础设施提供商,正在通过与Kubernetes的深度集成,为用户提供更加灵活、高效的云原生解决方案。从集群部署到运维管理,再到存储与网络,Oxide正在通过一系列创新的集成方案,将客户的实际需求转化为可落地的产品功能。**Kubernetes与Oxide的天然契合**Kubernetes通过标准化的扩展点(如云控制器管理器、容器存储接口等)定义了基础设施的预期行为,而Oxide则通过其丰富的API接口,为这些行为提供了底层实现的可能性。这种架构上的互补性,为两者的深度集成奠定了基础。然而,技术上的可能性并不等同于用户需求的直接满足。
在2024年底之前,尽管Kubernetes与Oxide在理论上可以完美协同,但缺乏成熟的集成方案,仍然阻碍了用户在Oxide上部署和运行Kubernetes集群。正是基于这一现状,Oxide决定投入资源,专注于解决客户在Kubernetes部署与运维过程中的实际痛点。作为Oxide首位专注于解决方案工程的软件工程师,Matthew Sanabria在加入公司后,便立即投入到这一关键项目中。他的首要任务是简化Kubernetes在Oxide上的部署与运维流程,而这一目标的实现,离不开对客户需求的深入理解与快速响应。**从客户需求到产品功能:迭代式开发的力量**Oxide的集成方案并非一蹴而就,而是通过与客户的密切互动,在实践中不断完善的。最初,公司收到了一位客户提交的Rancher节点驱动的Pull Request,以及RFD 493(Kubernetes初始集成)的早期草案。
这两份资料成为后续开发的起点,但真正推动项目进展的,是客户在实际使用过程中反馈的问题与需求。为了确保集成方案能够真正解决用户的痛点,Oxide采用了迭代式开发的方法。团队没有闭门造车,而是紧密跟踪客户在Kubernetes生命周期各个阶段遇到的挑战 - - 从集群部署、节点管理、网络配置,到存储需求与负载均衡。每一个阶段的问题都成为推动集成方案演进的动力,确保最终的产品不仅技术先进,更符合用户的实际使用场景。**集群部署:多种方案并行,满足不同用户需求**在Kubernetes集群的部署阶段,Oxide意识到单一的解决方案无法满足所有用户的需求。因此,公司最终发布了三种不同的集成方案,分别针对不同的用户场景与技术栈。
**Rancher节点驱动:简化Rancher用户的迁移路径**对于已经使用Rancher管理Kubernetes集群的用户而言,迁移到Oxide的最大障碍在于如何将Oxide的实例作为节点集成到Rancher管理的集群中。Rancher节点驱动正是为此而生的解决方案。作为一个可执行的插件,它教会Rancher如何在特定的基础设施平台上创建和管理虚拟机。Oxide的Rancher节点驱动通过将Rancher的操作转译为Oxide API请求,实现了两者之间的无缝对接。这一集成方案的开发过程本身也是一次学习与验证的过程。由于Matthew此前从未使用过Rancher或接触过节点驱动的概念,他通过审查客户提交的Pull Request,逐步理解了这一技术的工作原理。
经过测试验证后,他不仅合并了这一Pull Request,还为其添加了CI/CD流水线与文档改进,最终发布了Oxide的首个Kubernetes集成方案。这一成果不仅让Oxide拥有了第一个官方的Kubernetes集成,更让客户能够在生产环境中成功使用这一解决方案。**Omni基础设施提供商:与Sidero Labs的合作加速集成**除了Rancher之外,Oxide还与Sidero Labs合作,为Omni平台开发了基础设施提供商。Omni是一款专注于通过Talos Linux部署Kubernetes集群的平台,而Oxide的基础设施提供商则负责在Oxide上创建Talos Linux实例,并将其注册到Omni中。这一合作不仅展示了Oxide在KubeCon North America 2025上的技术实力,也为用户提供了另一种部署Kubernetes集群的选择。然而,这一开发过程并非一帆风顺。
在与Sidero Labs的合作中,Oxide团队发现了Talos Linux在文件系统探测方面的局限性。由于Oxide使用FAT12文件系统来存储cloud-init用户数据,而Talos Linux的文件系统探测器仅尝试读取ISO 9660超级块,导致无法正确读取用户数据。这一问题最终通过在用户数据中添加注释(以增加其大小,使其使用ISO 9660超级块)得以临时解决。尽管这一解决方案并不完美,但它展现了Oxide在面对技术挑战时的灵活性与创造力。**Cluster API提供商:Kubernetes原生的集群管理方式**如果说前两种集成方案依赖于第三方平台(如Rancher或Omni),那么Cluster API(CAPI)则提供了一种更加原生的Kubernetes集群管理方式。CAPI允许用户通过Kubernetes自定义资源声明式地创建、扩缩容、升级和删除集群,而基础设施提供商则负责处理平台特定的工作,如创建和删除虚拟机。
Oxide的Cluster API提供商(CAPOx)的开发过程体现了公司对用户需求的深度理解。最初,由于客户需求与工程资源的限制,这一项目被推迟。但随着客户对CAPI的需求日益增长,以及解决方案工程团队的壮大,CAPOx最终得以发布。这一提供商不仅为用户提供了Kubernetes原生的集群部署方式,还通过与其他集成方案的协同,实现了端到端的集群工作流管理。**运行时集成:云控制器管理器与负载均衡**集群部署仅仅是Kubernetes生命周期的第一步。在集群运行过程中,如何确保Kubernetes与Oxide基础设施之间的实时同步,以及如何支持负载均衡服务,成为用户关注的焦点。
**云控制器管理器:实现Kubernetes与Oxide的实时同步**为了确保Kubernetes能够准确跟踪Oxide实例的状态,Oxide开发了云控制器管理器(CCM)。这一组件在每个集群中运行,通过与Oxide API的交互,持续同步Oxide基础设施与Kubernetes状态。具体而言,CCM的节点控制器负责保持Kubernetes节点对象与其对应的Oxide实例之间的同步,记录实例ID、网络地址等详细信息,并报告实例是否正在运行、已关闭或不复存在。这一运行时集成不仅解决了节点状态的同步问题,还为后续的功能扩展奠定了基础。例如,CCM的服务控制器负责处理负载均衡服务,为用户提供更加完善的云原生体验。**负载均衡服务:利用浮动IP实现外部访问**在云原生环境中,负载均衡服务是确保应用高可用性的关键组件。
然而,由于Oxide在当时并未提供原生的负载均衡器,用户只能通过第三方解决方案(如MetalLB)来满足需求。为了弥补这一短板,Oxide团队决定利用Oxide的浮动IP(Floating IP)功能来支持Kubernetes的LoadBalancer服务。浮动IP是从机架外部IP池中分配的地址,可以附加到或分离自实例,使这些实例能够从其VPC外部访问。通过将浮动IP附加到单个Kubernetes节点,并利用Kubernetes服务数据平面将流量分发到相应的Pod,Oxide成功实现了对LoadBalancer服务的支持。然而,这一实现方式也带来了一些技术挑战。由于Oxide的浮动IP对实例透明,即实例的网络接口不会配置浮动IP,而是由Oxide网络层负责将目标地址转换为实例的内部IP。
因此,Kubernetes服务数据平面需要将节点的内部IP视为服务前端,以确保流量能够正确路由到Pod。为了解决这一问题,Oxide的服务控制器在status.loadBalancer.ingress中发布了两个条目:一个是浮动IP(以代理模式),另一个是节点的内部IP(以VIP模式)。尽管这一实现方式在kubectl输出中显得有些不寻常,但它有效地支持了常见的Kubernetes工作流,同时为未来引入原生负载均衡器留出了空间。**存储集成:持久化存储的挑战与解决方案**在Kubernetes集群中,持久化存储是部署有状态应用的关键需求。然而,由于Oxide在当时并未提供原生的容器存储接口(CSI)驱动,用户只能依赖第三方解决方案(如Longhorn)来管理存储。虽然Longhorn提供了自己的CSI驱动,并通过复制数据来确保高可用性,但这种方案在Oxide的分布式磁盘上叠加复制层,可能导致写放大问题。
为了解决这一问题,Oxide引入了本地磁盘(Local Disk)功能。本地磁盘没有内置复制,适合与Longhorn等需要跨节点复制数据的系统配合使用。通过这种方式,用户可以避免双重复制带来的性能开销,同时享受到更高效的存储管理体验。然而,Oxide团队并未止步于此。为了提供更加原生的存储集成方案,团队成员Luiz撰写了RFD 595(Oxide CSI插件)草案,旨在通过CSI驱动直接管理Oxide的分布式磁盘。然而,这一开发过程也遇到了技术障碍:Oxide要求在附加或分离磁盘之前必须停止实例,而Kubernetes期望CSI驱动能够在运行中的工作节点上附加存储。
这一矛盾需要通过在Oxide技术栈的各个层面(从虚拟机管理程序到API层)添加热插拔磁盘支持来解决。**展望未来:持续创新与生态建设**通过与客户的紧密合作,Oxide已经构建了一个相对完整的Kubernetes集成生态系统。从集群部署(Rancher、Omni、Cluster API)到运行时管理(云控制器管理器),再到存储与负载均衡,每一个环节都经过了实践的验证与优化。然而,Oxide并未满足于现状,而是继续在多个方向上进行探索与创新。**磁盘热插拔与CSI插件:突破存储瓶颈**磁盘热插拔与CSI插件的开发是Oxide当前的重点项目之一。通过支持磁盘的热插拔操作,用户将能够在不停止实例的情况下附加或分离磁盘,从而实现更加灵活的存储管理。
这一功能不仅将解决当前CSI插件开发中的技术障碍,还将为用户提供更加高效的存储操作体验。**自动扩缩容与外部子网支持:提升集群弹性**在集群管理方面,Oxide计划进一步完善自动扩缩容功能,使集群能够根据负载变化自动调整节点数量。此外,通过扩展云控制器管理器的服务控制器,Oxide还将支持外部子网,为用户提供更加灵活的网络配置选项。**资源标签与OIDC支持:增强治理与安全性**在资源管理与安全性方面,Oxide计划引入资源标签功能,使用户能够更加高效地组织和管理资源。同时,通过支持OIDC(OpenID Connect)身份验证,Oxide将为用户提供更加安全与便捷的访问控制机制。**原生负载均衡器:简化应用部署**尽管Oxide已经通过浮动IP实现了对LoadBalancer服务的支持,但原生负载均衡器的引入将进一步简化用户的应用部署流程。
通过与Kubernetes服务接口的无缝集成,原生负载均衡器将为用户提供更加高效与可靠的流量管理能力。**客户需求驱动的持续演进**Oxide的Kubernetes集成方案之所以能够不断演进,根本原因在于其对客户需求的深度理解与快速响应。通过与客户的密切互动,Oxide不仅能够及时发现并解决问题,还能够将客户的反馈转化为产品改进的动力。这种以客户为中心的开发理念,确保了Oxide的集成方案始终走在技术前沿,同时满足用户的实际需求。**技术架构的协同优势**Kubernetes与Oxide的集成不仅仅是软件层面的协同,更体现了硬件与软件的深度融合。Oxide的硬件与软件协同设计理念,使其能够在技术栈的各个层面(从虚拟机管理程序到API层)解决集成过程中的挑战。
例如,通过在虚拟机管理程序层面支持磁盘热插拔,Oxide能够为CSI插件的开发提供坚实的基础支持。**总结:构建更加开放与高效的云原生生态**Oxide通过与Kubernetes的深度集成,不仅为用户提供了更加灵活与高效的云原生解决方案,还展示了硬件与软件协同设计的巨大潜力。从集群部署到运维管理,再到存储与网络,每一个集成环节都经过了实践的验证与优化,确保最终的产品不仅技术先进,更符合用户的实际需求。未来,随着磁盘热插拔、原生负载均衡器等功能的逐步落地,Oxide的Kubernetes集成生态将变得更加完善与强大。通过持续创新与客户需求驱动的开发理念,Oxide正在为云原生技术的发展贡献力量,构建一个更加开放、高效与可持续的云原生生态系统。 。
