Oxide上のKubernetes：顧客のニーズが統合をどのように形成したか

2024年後半、顧客や見込み客はOxide上でKubernetesを実行することを熱望していましたが、それを支援するサポートされた統合は何もありませんでした。 KubernetesとOxideは自然な組み合わせです。Kubernetesは標準的な拡張ポイントを通じて期待するインフラストラクチャの動作を定義し、OxideはAPIを通じてその動作を実装するために必要なプリミティブを公開します。統合の基盤はそこにありました。欠けていたのはソフトウェアと、顧客が実際に必要としている統合の理解でした。 それが、私がOxideに最初のソリューションソフトウェアエンジニアとして入社したときの状況でした。[1] 顧客の問題を解決するソフトウェアの構築に重点を置いていました。私の最初の割り当ては、Oxide上でKubernetesをデプロイおよび運用しやすくすることでした。 最初の週に、開始を支援するために2つのリソースを渡されました。 顧客提出のRancherノードドライバーのプルリクエスト RFD 493 Initial Kubernetes Integrationsの初期ドラフト それらの2つのリソースから始まったものは、フィードバックループによって形成されたチームの努力へと成長しました。抽象的に統合を設計するのではなく、クラスターのプロビジョニングからワークロードの運用へと移行する際に顧客が遭遇した問題に従いました。 この記事では、厳密な時系列順ではなく、Kubernetesライフサイクル全体にわたるそれらの問題について説明します。さまざまなプロビジョニングワークフローが、Rancher、Omni、およびCluster APIへと私たちを導きました。クラスターの実行にはインフラストラクチャの同期が必要であり、アプリケーションの公開はネットワーキングのギャップを露呈し、ステートフルワークロードはストレージの制約を露呈しました。各段階で、顧客のワークフローが次のギャップを露呈し、私たちが構築した統合と、まだ進行中のプラットフォーム作業の両方を形成しました。 どうすればOxide上でKubernetesクラスターをプロビジョニングできますか？ 最初に解決したギャップはプロビジョニングでした。私たちの当面の目標は、Rancherノードドライバーのプルリクエストを提出した顧客のブロックを解除することでした。彼らのユースケースに取り組むことで、Oxide上でKubernetesクラスターを作成する実体験も得られ、解決すべき次の問題を発見するのに役立ちました。 単一のプロビジョニングアプローチがすべての顧客のワークフローに適合したわけではないため、最終的に3つの統合を公開しました。 Rancherノードドライバー 顧客提出の統合を維持する前に、それがサポートするワークフローを理解する必要がありました。私はRancherを使用したことも、ノードドライバーで作業したこともなかったので、貢献をレビューすることは両方を学ぶことを意味しました。 Rancherノードドライバーは、Rancherに特定のインフラストラクチャプラットフォーム上の仮想マシンを作成および管理する方法を教える実行可能なプラグインです。Oxide Rancherノードドライバーは、それらの操作をOxide APIリクエストに変換します。Rancherにインストールされると、顧客はOxideインスタンスをRancher管理のKubernetesクラスターのノードとしてプロビジョニングできるようになります。 テストにより、顧客の実装が機能することが確認されました。プルリクエストをマージし、CI/CDとドキュメントの改善を追加し、最初のリリースを公開しました。Oxideは公式に最初のKubernetes統合を持ち、顧客はすでに本番環境で正常に使用していました！ RancherショップでOxide上でKubernetesを実行したい場合は、Rancherガイドを参照してください。 Omniインフラストラクチャプロバイダー 顧客は、Talos Linuxを実行するKubernetesクラスターをプロビジョニングするためにSidero LabsのOmniを使用することに関心を示しました。Omniは、インフラストラクチャプロバイダーを通じてインフラストラクチャプラットフォームに接続します。これは、Talos Linuxインスタンスを作成し、それらをOmniに登録するプログラムです。 KubeCon North America 2025が数ヶ月後に迫っていたため、OmniのOxideインフラストラクチャプロバイダーを構築して紹介するためにSidero Labsと提携する機会を見出しました。私たちのOxide+Sideroイベントまでに完了するために7週間ありました。[2] 2番目のプロビジョニングプラットフォームに対して構築することは、異なる顧客ワークフロー全体でOxideのAPIをテストすることにもなりました。 統合作業により、OmniとTalos Linux全体でいくつかの問題が明らかになりました。それらの問題をSidero Labsにsiderolabs/omni#1633で提起したところ、彼らのチームは私たちと協力することに熱心でした。これは、RFD 68 Partnership as Shared Valuesを思い出させる素晴らしい機会でした。 最も記憶に残っている問題はsiderolabs/talos#11948でした。OxideはISO 9660ではなくcloud-initのuser-dataにFAT12ファイルシステムを使用していますが、TalosのファイルシステムプローブはNoCloud構成ディスクからISO 9660スーパーブロックのみを読み取ろうとしました。その読み取りが失敗すると、プローブは停止し、VFATやMS-DOSなどの他の形式を試行しませんでした。その結果、TalosはOmniに参加するために必要な構成を含むOxideユーザーデータを読み取ることができませんでした。修正はKubeConまでにリリースされなかったため、かなり面白い回避策が残りました。 現在の回避策は、user-dataをコメントでパディングしてサイズを大きくし、ISO 9660スーパーブロックを使用するようにすることです。 KubeConが到着し、OmniのOxideインフラストラクチャプロバイダーを紹介するOxide+Sideroイベントを開催しました。顧客は、このインフラストラクチャプロバイダーを使用して、Omni管理のKubernetesクラスターのノードとしてTalos Linuxを実行するOxideインスタンスをプロビジョニングできるようになりました。 OmniまたはTalos LinuxショップでOxide上でKubernetesを実行したい場合は、Omniガイドを参照してください。 Cluster APIプロバイダー RFD 493 Initial Kubernetes Integrationsを最初に作成したときに、Kubernetes Cluster API（CAPI）用のインフラストラクチャプロバイダーを構築したいと考えていました。Cluster APIは、最初の2つの統合にはないものを提供しました。それは、RancherやOmniのようなサードパーティプラットフォームを必要とせずにクラスターを管理するための、アップストリームでプロバイダー拡張可能なAPIです。 CAPIにより、オペレーターはKubernetesカスタムリソースを通じてKubernetesクラスターを宣言的に作成、スケーリング、アップグレード、および削除できます。インフラストラクチャプロバイダーは、仮想マシンの作成と削除などのプラットフォーム固有の作業を処理します。それらを構築することは大きな投資です。当時、顧客の需要とエンジニアリング能力はまだその投資を正当化していなかったため、プロジェクトは延期されました。 最終的に、両方が変化しました。顧客はCAPIプロバイダーを要求し始め、ソリューションソフトウェアエンジニアリングチームは成長しました。私のチームメイトであるJoshとBrandonが作業を引き継ぎ、Cluster API Provider Oxide（CAPOx）をリリースし、顧客にOxide上でクラスターをプロビジョニングするためのKubernetesネイティブな方法を提供しました。 Cluster APIワークフローは、他のいくつかの統合も実行し、エンドツーエンドのクラスターワークフローをドッグフード[3]できるようにします。Kubernetes Image Builderは、Packerプラグインを使用してCAPI対応のOxide VMイメージを作成し、CAPOxはインスタンスをプロビジョニングするときにそれを使用します。CAPOxでプロビジョニングされたクラスターは、別途インストールされたOxide Cloud Controller Manager（CCM）も使用して、実行時にKubernetesとOxideを統合します。 Cluster APIでOxide上にKubernetesクラスターをプロビジョニングしたい場合は、Cluster APIガイドを参照してください。 KubernetesはOxideインスタンスをどのように追跡しますか？ プロビジョニング統合はOxideインスタンスを作成および管理しますが、それらのインスタンスをKubernetesノードオブジェクトと同期しません。その同期がないと、クラスターは到達不可能なKubernetesノードが一時的に利用できないのか、それともバックエンドのOxideインスタンスが削除されたのかを確実に判断できませんでした。 各クラスターで実行され、Oxide APIと通信し、OxideインフラストラクチャとKubernetesの状態を継続的に同期するコンポーネントが必要でした。Kubernetesはこの目的のために標準的な拡張ポイントを提供します。それがCloud Controller Manager（CCM）です。CCMにより、インフラストラクチャ固有のコントローラーは、Kubernetes自体にプロバイダー固有のコードを追加することなく、KubernetesリソースをインフラストラクチャプロバイダーのAPIと統合できます。 KubernetesとOxideを接続するために、Oxide Cloud Controller Managerを構築しました。そのノードコントローラーは、KubernetesノードオブジェクトをバックエンドのOxideインスタンスと同期させ、インスタンスIDやネットワークアドレスなどの詳細を記録し、各インスタンスが実行中、シャットダウン中、または存在しないかを報告します。Kubernetesは、この情報を使用してノードを初期化し、バックエンドインスタンスが削除されたときに安全に削除します。 CCMはインスタンスを作成したりクラスターをプロビジョニングしたりしません。それは、Rancherノードドライバー、