Oxide上のKubernetes：顧客の声から生まれたインテグレーションの裏側

この記事では、Oxide環境においてKubernetesがどのように実装されているのか、そして顧客からのフィードバックがいかにして我々のインテグレーション戦略を形作ってきたのかを詳しく解説します。

「modern」なKubernetes向けに oxide-cloud-controller-manager がどう構築されているのか、そして従来のin-treeから派生したCCMと比べて何か大きな違いがあるのか興味があるな。Oxideのエンジニアリング手法を考えると、かなり面白そうだ。ちなみに、俺のビンゴカードには karpenter-provider-oxide が入ってるぞ...

彼らのドキュメントシステム、マジでオープンソース化してほしい。

家にOxideのラックを置くことほど、今まで強く望んだものはないな。40年後くらいにサープラス品として競売に出てくるのを待つしかないのか...

CAPOxプロバイダーが登場してCluster APIに対応するのは嬉しいね

素人考えだけど、Kubernetesに関してはOxideはまだパブリッククラウドに完全には追いついていない気がする。AWS EKS Fargateなら各Podが専用VMで動くけど、Oxideではk8sのノード自体がVMだから、結局Talosみたいなものが必要になるよね。ネットワーク周りは近づいてきているようで、外部サブネットからオーバーレイなしでPodにルーティング可能なIPを割り当てられるようにはなりそうだけど、記事でも指摘されている通り、ロードバランシングのギャップがある。Kubernetesが最初からネイティブ機能として統合されていて、かつ既存のユーザー/アクセス制御と連携できたら最高なんだけどな。

つまり、PVCごとに稼働中のワーカーVMへ新しいボリュームをアタッチするってこと？なんだか少し奇妙に感じるな。大きなボリュームを一つアタッチして、その中でパスベースのプロビジョニングをするんじゃダメなのか？

素朴な疑問なんだけど、ベアメタルでKubevirtを使ってKubernetesを動かすのと、Oxide上でKubernetesを使うのはどういう違いがあるんだ？一見すると、OxideはProxmoxや仮想化ツールと同等のものに思えるし、裏でqemuなんかを使っているのかなと。うちはオンプレ環境が多くて、k8sと密接に連携しているから、Kubernetes API互換 [1] でありつつ、containerdやWASM、あるいは我々のプラットフォーム上でネイティブに動く社内プロジェクトを開発中なんだ。このシナリオでOxideがどう機能するのか興味があるよ。 [1] https://github.com/debarshibasak/superkube

免責：完全に偏った意見だけど。2024年にOxideの同僚とKubernetesの展望について話した時は「まだだけど、もうすぐ」って言ってたんだ。その「もうすぐ」が今ってわけだね :) 当時、実現したらまた話そうと言ってたんだけど、彼はその後Oxideを去ってしまった。もし君（あるいは君の顧客）が、100%オープンソースのKubernetesネイティブなデータプラットフォームに興味があるなら、どうやって簡単に実現できるかぜひ話したい。Kubernetesが「ただ」動いているだけなら簡単なはずだけど、テストしてリストに加えられたら嬉しいな: https://docs.stackable.tech/home/stable/kubernetes/#supporte... この話は有効だよ。興味があればHNプロフィールにあるメールアドレスまで連絡してくれ。https://stackable.tech

バグ報告になると思うけど、iPadで見るとページ上部のナビゲーションが完全に機能していないみたいだ。指でクリックしても反応しないし、Apple Pencilでクリックしてもダメ。ホバーステートがあるはずの箇所も（ペンで試したけど）反応しないんだ。

彼らのハイパーバイザーを挟まずに、ベアメタルハードウェア上で直接Kubernetesを動かせたらもっとクールだと思うんだけどな