2024年底，客户急需在Oxide上运行Kubernetes，但缺乏支持集成。工程师入职后，从客户提交的Rancher驱动和内部设计文档入手，通过客户反馈循环逐步构建集成方案。

2024年底，客户和潜在用户迫切希望在Oxide平台上运行Kubernetes，但当时缺乏官方支持的集成方案。Kubernetes与Oxide天然契合：Kubernetes通过标准扩展点定义基础设施行为，而Oxide通过API提供实现这些行为所需的基础组件。集成的基础已经具备，但缺少的是软件实现以及对客户实际需求的清晰理解。

我作为Oxide首位解决方案软件工程师入职时，首要任务就是简化在Oxide上部署和运维Kubernetes的流程。最初的两份资源——客户提交的Rancher节点驱动拉取请求和Kubernetes集成初步设计草案——成为工作的起点。我们并未闭门造车设计集成方案，而是紧密跟随客户从集群部署到工作负载运维过程中遇到的实际问题，逐步推进。

针对集群部署，我们发布了三种集成方案：Rancher节点驱动、Omni基础设施提供者和Cluster API提供者。Rancher节点驱动将Oxide API操作转化为Rancher可识别的虚拟机管理指令；Omni基础设施提供者与Sidero Labs合作，支持在Oxide上运行Talos Linux节点；Cluster API提供者则提供了无需第三方平台的、基于Kubernetes原生API的集群管理方式。

在运行时集成方面，我们构建了Oxide云控制器管理器（CCM），负责持续同步Kubernetes节点对象与底层Oxide实例的状态。CCM还通过浮动IP技术实现了对LoadBalancer服务的支持——虽然当前方案存在抽象不完美的局限，但已能支撑常见工作负载，待原生负载均衡功能上线后可无缝升级。

存储集成面临挑战：Oxide要求实例停机后才能挂载或卸载磁盘，这与Kubernetes期望的运行时热插拔需求冲突。目前我们正推进磁盘热插拔功能的全栈开发，同时客户可先用Longhorn配合Oxide本地磁盘实现持久化存储，避免双层复制带来的写放大问题。

这些集成工作不仅解决了客户痛点，更验证了Kubernetes与Oxide架构的互补性。未来我们将继续完善磁盘热插拔、CSI插件、自动扩缩容、外部子网支持等功能，并随着Oxide平台功能演进持续扩展集成生态。

根据评论内容，总结如下：

主要观点与论据：

1. 对Oxide Kubernetes集成的期待与比较（评分：None）

   • 评论1：关注oxide-cloud-controller-manager如何构建“现代”Kubernetes，以及是否与树内CCM有显著差异。关键引用："I'm interested to see how the oxide-cloud-controller-manager is being built for 'modern' Kubernetes"。
   • 评论5：指出Oxide在Kubernetes方面尚未完全匹配公有云，如AWS EKS Fargate每个Pod有独立VM，而Oxide每个节点是VM，仍需Talos；网络接近但负载均衡有差距。关键引用："Kubernetes is where Oxide... doesn't yet quite match the public cloud"。

2. 对Oxide硬件与文档系统的兴趣（评分：None）

   • 评论2：强烈希望Oxide开源其文档系统。关键引用："I would absolutely kill for them to open source their documentation system"。
   • 评论3：渴望拥有Oxide机架，但预计40年后才可能出现在二手市场。关键引用："I have seldom wanted anything as much as I want an Oxide rack at home"。

3. 对Oxide与Kubernetes集成的技术疑问（评分：None）

   • 评论6：质疑PVC挂载方式，建议使用单一大卷进行路径级配置。关键引用："Could you attach a single large volume, and do path-based provisioning on that?"。
   • 评论7：比较Oxide上运行Kubernetes与裸金属上使用Kubevirt，认为Oxide类似Proxmox或虚拟化工具。关键引用："I am wondering when would you use kubernetes on oxide vs running kubernetes with kubevirt on baremetal?"。
   • 评论8：询问如何在Oxide上管理有状态工作负载（如数据库）。关键引用："How are folks managing stateful workloads like databases on Oxide?"。

4. 对Oxide Kubernetes生态的积极反馈（评分：None）

   • 评论4：赞赏CAPOx提供商并支持Cluster API。关键引用："Love to see the CAPOx provider and buy in to Cluster API"。
   • 评论9：期待Oxide的Kubernetes故事，并邀请合作。关键引用："Seems like soon-ish is now :)"。

平衡性总结： - 正面观点：对Oxide的硬件、文档系统、Kubernetes集成（如CAPOx）有高度兴趣和期待，认为其工程方法可能带来创新。 - 负面/质疑观点：指出Oxide在Kubernetes方面与公有云存在差距（如Pod隔离、负载均衡），技术实现（如PVC挂载）有疑问，且与现有虚拟化工具（如Proxmox）相比优势不明确。 - 中立/技术性观点：关注具体实现细节（如网络、存储、有状态工作负载），并期待未来改进。