8月13日、Oxide Computerが「Kubernetes on Oxide: How Customer Needs Shaped Our Integrations」と題した記事を公開した。顧客のニーズを起点にKubernetes統合を段階的に構築してきた同社の開発の舞台裏が、珍しいほど率直な筆致で記されている。
アプリケーションからの1回の書き込みが最大9回の物理ディスク書き込みに増幅される——。これは怠慢な実装ではなく、ハードウェアからAPIまでを垂直統合したOxide固有のアーキテクチャと、Kubernetesのストレージモデルがぶつかった結果だ。そしてこの問題を本筋で解決しようとしたチームは、Kubernetes統合という出発点から「ハイパーバイザー全体のホットプラグ対応」という大規模な開発課題へと引き込まれることになる。
ハードウェア統合クラウドとKubernetesの相性問題
Oxide Computerは、ハードウェアからハイパーバイザー、APIまでを自社で設計・管理するラックサーバー製品を展開している。AWSやGCPのように汎用ハードウェア上に既存のOSSスタックを重ねるのではなく、ソフトウェアとハードウェアを一体として開発している点が特徴だ。2023年以降、オンプレミスのプライベートクラウドを求める企業向けに存在感を高めており、主にセキュリティ・コンプライアンス要件の厳しい組織や、クラウドコストの最適化を図る企業が導入対象となっている。
この垂直統合モデルの強みは一貫した品質と深い最適化にある。しかしKubernetesのような上位レイヤーのエコシステムを取り込む際には、既存のクラウドプロバイダー向け統合をそのまま流用できず、独自コンポーネントを一から作る必要が生じる。記事では、クラスターのプロビジョニングやネットワーク到達性を確保した後、次の難題として浮上したストレージ統合の問題が中心に語られている。
「二重レプリケーション問題」とは何か
Kubernetesのステートフルワークロードは、PersistentVolumeClaimを通じてストレージを要求し、CSI（Container Storage Interface）ドライバーがボリュームのライフサイクルを管理する。OxideにはKubernetesが管理できるディスクが存在するが、これをネイティブに扱う手段がなかったため、暫定策としてサードパーティのストレージシステムであるLonghornの利用が検討された。LonghornはKubernetesワーカー間でデータをレプリケーションするCSIドライバーを備えており、Kubernetesクラスター上に分散ストレージを構築できる。
ところがここで構造的な問題が発生した。
Oxideの分散ディスクは、内部的にすでに3つの異なるsled（Oxideラック内の演算・ストレージ基板ユニット。公式ドキュメント参照）上に3レプリカを保持している。一方、LonghornのデフォルトもKubernetesノードをまたいだ3レプリカ構成だ。この二つを素直に組み合わせると、アプリケーションからの1回の書き込みが最大9回の物理ディスク書き込みに増幅される（3 × 3のファンアウト）。書き込みコストが膨れ上がるだけでなく、Oxideがすでに保証している耐久性とは無関係にLonghorn側のレプリケーションが二重で走るという意味でも無駄が大きい。
この問題を部分的に解消したのが、Oxideのローカルディスクだ。ローカルディスクはレプリケーションなしで特定のsledに固定されるため、Longhornのような上位レプリケーション層との相性が良い。GitHubのRancher showcaseでは、ローカルディスクを使った具体的な構成例が公開されている。ただしこの方法はあくまでLonghornが管理主体であり、Oxideネイティブな統合には程遠い。
ネイティブCSIプラグインを阻んだ「ホットプラグ」問題
Oxide本来のネイティブCSI統合を実現すべく、チームメンバーのLuizがRFD 595 Oxide CSI Pluginを執筆した。設計上のワークフローは単純だ：
- ユーザーが
PersistentVolumeClaimを作成 - CSIコントローラーがOxideの分散ディスクを作成
- Kubernetesがポッドをスケジュールすると、対象インスタンスにディスクをアタッチ
- ポッドが別ノードに再スケジュールされたら、ディスクをデタッチして再アタッチ
しかしプロトタイピングの段階で致命的なブロッカーが露見した。Oxideは現時点で、ディスクのアタッチとデタッチの前にインスタンスを停止する必要がある。 Kubernetesは動作中のワーカーへCSIドライバーがオンラインでストレージをアタッチすること——いわゆるホットプラグ——を前提としているため、この制約は根本的な非互換だ。インスタンスを停止すれば、そのノード上の全ワークロードに影響が及び、スケジューリングの連鎖が発生する。
解決策は明確だ。ハイパーバイザーからAPIまで、Oxideのソフトウェアスタック全体にわたってディスクホットプラグに対応する必要がある。 Kubernetes統合を起点にしたはずのプロジェクトが、複数のシステム層をまたぐ大規模な開発課題に発展した形だ。自前のスタックを持つことの強み——深い最適化が可能——は、このような場面では全層を自分で直す責任にもなる。
現状と今後
執筆時点でディスクホットプラグとOxide CSIプラグインはいずれも開発中だ。現時点で利用可能な選択肢は以下の通りである：
- Oxide分散ディスク + Longhorn：二重レプリケーションが発生するため非推奨
- Oxideローカルディスク + Longhorn：二重レプリケーションを回避できる現実的な選択肢
ネイティブCSIプラグインがリリースされれば、Oxideが保証するレプリケーションと耐久性をそのまま活かしつつ、使い慣れたKubernetesのストレージAPIが利用できるようになる。ホットプラグ対応はCSI統合にとどまらず、他のさまざまなユースケースにも波及する基盤的な改善であり、完成すればOxideプラットフォーム全体の柔軟性が大きく向上するはずだ。
詳細はKubernetes on Oxide: How Customer Needs Shaped Our Integrationsを参照していただきたい。
