OxideがKubernetesの3つのパスを詳細に説明、ネイティブストレージはまだ未完成

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統合から、3つのプロビジョニング経路と共有のランタイムコントローラを維持する体制へと移行したと詳述した。

8月13日付のテクニカルアカウントは、残る作業の極めて直接的な棚卸しも示している。Oxideには依然としてネイティブのロードバランシングサービスがなく、ネイティブのKubernetesストレージドライバは、Cloud Computerがインスタンス実行中にディスクをアタッチ／デタッチできないことに阻まれている。

これらの制約は、Kubernetes対応が創業者の元の賭けの試金石であることを意味する。TuckとCantrillは、オンプレミスのインフラストラクチャはハードウェア、ストレージ、ネットワーキング、制御ソフトウェアを一体設計した統合されたクラウドコンピュータとして提供されるべきだという考えのもとでOxideを構築した。Kubernetesは、その統合されたスタックに対して、開発者がパブリッククラウドプロバイダに期待するのと同じインフラ契約を満たすことを要求している。

Matthew SanabriaはOxideに最初のSolutions Software Engineerとして参加し、その仕事を顧客と製品の境界をまたいで担ってきた。彼の最初の課題は、顧客が提出したプルリクエストと内部ロードマップ、RFD 493から始まった。最終的にそれはRancher、Sidero LabsのOmni、Kubernetes Cluster API向けの統合と、それらのプロビジョニングシステム間で共有されるクラウドコントローラマネージャを生み出した。

Customer code became the roadmap

最初の統合はOxideの外部から来た。顧客が提出したRancherのノードドライバのプルリクエストは、Rancherのプロビジョニング操作をOxideのAPI呼び出しに翻訳するものだった。Sanabriaはその実装をテストし、マージし、CI/CDとドキュメントを追加して、初期リリースを公開した。

Sanabriaによれば、その顧客は既にプロダクションでそのドライバを稼働させていた。Oxideは顧客の身元、クラスターサイズ、ワークロードプロファイルを公表していないため、その稼働主張は独立した計測によるものではなくベンダー側の説明に留まる。それでもこの貢献はOxideに具体的な出発点を与えた。つまり、推測的な統合計画ではなく、実際のオペレータのワークフローを中心に書かれたソフトウェアだ。

そのパターンはSidero LabsのOmni統合でも続いた。顧客はOxide上でTalos LinuxマシンをプロビジョニングしてOmniに登録したかった。Oxideは2025年9月24日に作業を開始し、SanabriaのグループにOxideとSideroのイベントがある11月12日までの7週間を与えた。

その締め切りは低レベルの互換性バグを露呈した。Oxideはcloud-initのユーザーデータをFAT12ファイルシステムで提示している一方、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ネイティブな経路を提供する。

これら3つの統合はオペレータの好みに応じて異なる選択肢を提供する。Rancherは既存のRancher環境に適合する。OmniはTalos LinuxとSideroのライフサイクルツールを組み合わせる。CAPOxは上流のCluster APIモデルを通じてクラスタ基盤を管理させる。Oxideの現在のKubernetesドキュメントは、最も完成度の高いマネージドプロビジョニングオプションとしてRancherかOmniを推奨しており、CAPOxはエンジニアリングチームが自らのインフラでテストするためのもう一つのエンドツーエンドシステムを提供する。

Kubernetes exposed the platform gaps

仮想マシンをプロビジョニングすることは、Kubernetesを運用するための最初の部分しか解決しない。クラスタが稼働した後、Kubernetesはその下にあるインフラストラクチャの信頼できるビューを必要とする。OxideはKubernetesのNodeオブジェクトをOxideのインスタンスと照合し、アドレス、インスタンス識別子、マシンの状態などの詳細を報告するためのオープンソースのcloud controller managerを構築した。

このコントローラは、Oxideがネイティブのロードバランシングサービスをまだ出荷していないにもかかわらず、Kubernetesの型 LoadBalancer のサービスも扱う。Oxideは暫定的な仕組みとしてフローティングIPアドレスを使用している。コントローラは適格なKubernetesノードにフローティングIPをアタッチし、その後はクラスタ内のサービスデータプレーンにトラフィックをターゲットポッドへルーティングさせる。

このアプローチは馴染みのあるKubernetes APIをサポートしつつ、その下で不完全な実装を露呈させる。ユーザーはKubernetesの出力で外部到達可能なフローティングIPとノードの内部アドレスの両方を見ることになる。Oxideのcloud controller managerのドキュメントによれば、service controllerはフローティングIPを名前でソートした最初のノードに割り当ててアタッチする。コントローラは現在 externalTrafficPolicy: Cluster をサポートしており、その設定では当該ノードがクラスタ内の他のエンドポイントへトラフィックを転送できる。

ストレージはより困難な制約を提示する。KubernetesはContainer Storage InterfaceドライバがPodのスケジューリング後にボリュームを作成してアタッチすることを期待する。Oxideは現在、インスタンスを停止する前提でしかディスクのアタッチやデタッチを行えない。Kubernetesワーカを1つのボリューム操作のために停止すると、そのワーカ上の他のワークロードが中断され、さらなるスケジューリングやストレージの変更を引き起こす可能性がある。

したがってネイティブなOxide CSIプラグインは、ハイパーバイザ、コントロールプレーン、API全体にわたるディスクのホットプラグ対応に依存する。Kubernetesは、欠けている統合をハードウェアからソフトウェアスタック全体に及ぶプラットフォーム要件へと変換している。

The founders' integration bet gets tested in production

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要望から始まりハイパーバイザ内部に終わるようなプラットフォーム作業を含め、配達後も資本集約的な物理製品を拡張し続ける余地を得た。

Sanabriaの説明は、その支出の背後にある運用モデルを示している。最初のRancherコードは顧客が供給した。Omniの顧客はOxideとSideroにファイルシステムの想定をデバッグさせた。Cluster APIへの需要がより大きな実装を正当化した。ステートフルなワークロードはディスクのホットプラグの必要性を露呈させた。

Oxideは現在、Kubernetesのプロビジョニングとランタイム統合を持ち、Sanabriaによれば少なくとも1つの顧客が既にプロダクションで利用しているソフトウェアを含んでいる。ネイティブCSIストレージとネイティブロードバランシングは依然として未完成のままだ。未完成の各部分は、クラウドコンピュータ全体を所有することでオンプレミスインフラをクラウドサービスのように振る舞わせられるという創業者の約束に対するさらなる試練を意味している。