RustでKubernetesをゼロから書き直す：Rusternetesプロジェクトの概要
Rustで何かをゼロから書き直す試みは、システムプログラミングの人間の間で、もはや古典的なパターンとなっています。通常、こうした試みは「Hello World」段階か、基本的な設定ファイルの解析程度で終わることが多いです。しかしRusternetesでは、物語はまったく異なる展開を迎えました。プロジェクトの著者はKubernetes自体に真っ向から挑み、ゼロから書き直したのです。
これはGoコードのラッパーでも、機能を削ぎ落としたテスト用のモックでもありません。リポジトリには本格的なコントロールプレーンとノードコンポーネントが含まれています：APIサーバ、スケジューラ、コントローラマネージャ、kubelet、kube-proxy。すべてがRustで書かれており、サードパーティのGo依存関係はありません。
このプロジェクトは216,000行以上のコードを含み、10個のクレート、31個のコントローラ、3,100以上のユニットテストに分割されています。開発者はSonobuoy経由で公式のKubernetes e2eテストスイート（v1.35）を使用して互換性を検証しています。現在、Rusternetesは適合性テストの94%（441件中415件）に成功裏に合格しています。
なぜ別のKubernetesなのか
元のKubernetesはGoで書かれており 상당なリソースを必要とします。minikubeやk3sのような最小限のローカルクラスタを立ち上げるだけでも、仮想マシンを割り当てたり、etcdを含む複数の重いコンテナを実行したりする必要があります。
Rusternetesは柔軟なデプロイメントオプションでこの問題を解決します。3つの動作モードがあります：
- etcdを使ったクラシッククラスタ。すべてのコンポーネントが別々のコンテナで実行され、etcdクラスタと通信します。
- etcdの代わりにSQLiteまたはRedisを使用。etcdの代わりに、Rustで書かれたetcd互換のgRPCサーバであるRhinoが接続されます。API設定とバイナリは同じままです。composeファイルだけが変更されます。
- 単一バイナリ内の全コンポーネント。APIサーバ、スケジューラ、コントローラマネージャ、kubelet、kube-proxyが単一プロセス内でTokio非同期タスクとして実行されます。クラスタの状態は単一のSQLiteファイルまたはRedisインスタンスに書き込まれます。
All-in-Oneモードは、ローカル開発、CI/CDパイプライン、エッジデバイス（Edge/IoT）でのオーケストレータの実行における痛みを解決します。これらの環境ではRAMの每一メガバイトが重要です。
組み込みWebインターフェース
Rusternetesには組み込みのモニタリングダッシュボードがあります。APIサーババイナリに直接埋め込まれているため、追加の設定やデプロイメントは不要です。
インターフェースにはトラフィックアニメーション付きのクラスタトポロジマップ、CPUとRAMの負荷ヒートマップ、コンテナログのストリーミングが表示され、ConfigMap、Secrets、RBACマニフェスト、デプロイメントステータスの確認も可能です。
内部構造：プロジェクトアーキテクチャ
リポジトリは10個のクレートを持つCargoワークスペースとして構成されています。
┌───────────────────────────────────────────────────────────────┐
│ Control Plane │
│ │
│ ┌──────────────────┐ ┌──────────────┐ ┌────────────────┐ │
│ │ API Server │ │ Scheduler │ │ Controller │ │
│ │ Axum + TLS │ │ Affinity │ │ Taints │ │
│ │ REST + Watch │ │ Preemption │ │ Manager │ │
│ │ RBAC + Webhooks │ │ │ │ 31 control │ │
│ │ Web Console │ │ │ │ loops │ │
│ └────────┬─────────┘ └──────────────┘ └────────────────┘ │
│ │ │
│ ┌────────▼─────────┐ │
│ │ Storage │ │
│ │ etcd|SQLite|Redis│ │
│ └──────────────────┘ │
├───────────────────────────────────────────────────────────────┤
│ Node Components │
│ │
│ ┌──────────────────┐ ┌──────────────────────────────────┐ │
│ │ Kubelet │ │ Kube-Proxy │ │
│ │ bollard (Docker)│ │ iptables routing │ │
│ │ Probes+Volumes │ │ ClusterIP/NodePort/LB │ │
│ └──────────────────┘ └──────────────────────────────────┘ │
└───────────────────────────────────────────────────────────────┘
クラスタの各部分はそれぞれの担当領域を持ちます：
- api-server: Axumフレームワークを使用して書かれています。REST API、Server-Sent EventsによるWatch API、バリデーションとミューテーショ=webhook、CELルール評価、RBAC認可を処理します。
- scheduler: アフィニティ/アンチアフィニティ、taint、トレラレーション、リソース制約に基づいてPodのノード選択を行います。
- controller-manager: 31個のリコンシリエーションループを含みます。Deployment、ReplicaSet、StatefulSet、DaemonSet、Job、CronJob、HPA、Ingress、CRDを処理します。
- kubelet:
bollardcrate経由でDockerまたはPodmanと通信します。コンテナライフサイクルを追跡し、livenessとreadinessプローブを実行し、ボリューム（hostPath、configMap、secret）をマウントします。 - kube-proxy: ClusterIP、NodePort、LoadBalancerサービスタイプのiptablesルールを管理します。
テスト用の実行方法
ビルドには、最新のRust、protobufコンパイラ、DockerまたはPodmanが必要です。
テストする一番 빠른方法はSQLiteを使ったAll-in-Oneモードです：
cargo build -p rusternetes
./target/release/rusternetes --data-dir ./cluster.db
Docker Composeを使ってマルチコンポーネント環境のより本格的なエミュレーションを立ち上げる場合は：
git clone https://github.com/calfonso/rusternetes.git
cd rusternetes
export KUBELET_VOLUMES_PATH=$(pwd)/.rusternetes/volumes
docker compose -f docker-compose.sqlite.yml build
docker compose -f docker-compose.sqlite.yml up -d
bash scripts/bootstrap-cluster.sh
export KUBECONFIG=~/.kube/rusternetes-config
kubectl get nodes
ブートストラップ後、标准的なkubectlユーティリティを使ってクラスタとやり取りできます。
実用性と結論
現時点でRusternetesを本番環境に導入するのは不值得です。プロジェクトはe2eテストの94%に合格していますが、まだ実験的な段階です。それでも、3つの優れたユースケースがあります。
まず第一に、Kubernetesの内部を学ぶための理想的な学習教材です。明確なモジュール分割されたRustのソースコードを読むことは、元のK8sの巨大なモノリスに潜り込むよりもはるかに愉快です。
第二に、SQLiteを使って単一プロセスでクラスタを実行すると、テスト環境やCI/CDのリソースを節約できます。
第三に、Raspberry Piや組み込みIoTプラットフォームのような脆弱なハードウェア上でのオーケストレーションの実行に有用です。
Rustでのシステムプログラミングやオーケストレータの動作に興味があれば、このプロジェクトは確かにGitHubでスターを付ける価値があります。
関連プロジェクト