Réécrire Kubernetes from Scratch en Rust : Un regard sur le projet Rusternetes

Les blagues sur les programmeurs systèmes qui tentent de tout réécrire en Rust sont devenues un grand classique. Habituellement, de tels projets n'atteignent jamais le stade du "Hello World" ou du parsing de configurations basiques. Mais avec Rusternetes, l'histoire s'est révélée complètement différente. L'auteur du projet s'en est pris à Kubernetes lui-même et l'a réécrit from scratch.

Ce n'est pas un wrapper autour de code Go ni une maquette de test simplifiée. Le dépôt contient un plan de contrôle et des composants de nœud complets : serveur API, planificateur, gestionnaire de contrôleurs, kubelet et kube-proxy. Tout est écrit en Rust sans dépendances Go tierces.

Le projet contient plus de 216 000 lignes de code, réparties sur 10 crates, 31 contrôleurs et plus de 3 100 tests unitaires. Les développeurs vérifient la compatibilité à l'aide de la suite de tests e2e officielle de Kubernetes (v1.35) via Sonobuoy. Actuellement, Rusternetes passe avec succès 94% des tests de conformité (415 sur 441).

Pourquoi un autre Kubernetes

Kubernetes est écrit à l'origine en Go et nécessite des ressources considérables. Pour démarrer même un cluster local minimal comme minikube ou k3s, il faut allouer une machine virtuelle ou exécuter plusieurs conteneurs lourds avec etcd.

Rusternetes résout ce problème avec des options de déploiement flexibles. Il dispose de trois modes de fonctionnement :

1. Cluster classique avec etcd. Tous les composants s'exécutent dans des conteneurs séparés et communiquent avec un cluster etcd.
2. Remplacer etcd par SQLite ou Redis. Au lieu de etcd, Rhino est connecté—un serveur gRPC compatible etcd écrit en Rust. Les paramètres et binaires de l'API restent les mêmes ; seul le fichier compose change.
3. Tous les composants dans un seul binaire. Le serveur API, le planificateur, le gestionnaire de contrôleurs, kubelet et kube-proxy s'exécutent en tant que tâches async Tokio dans un seul processus. L'état du cluster est écrit dans un seul fichier SQLite ou une instance Redis.

Le mode All-in-One résout les points douloureux du développement local, des pipelines CI/CD et de l'exécution de l'orchestrateur sur les appareils edge (Edge/IoT), où chaque mégaoctet de RAM compte.

Interface Web Intégrée

Rusternetes dispose d'un tableau de bord de monitoring intégré. Il est embarqué directement dans le binaire du serveur API, donc rien de supplémentaire n'a besoin d'être configuré ou déployé.

L'interface affiche une carte de topologie du cluster avec animation du trafic, une heatmap de charge CPU et RAM, un streaming des logs des conteneurs, et permet de visualiser les ConfigMap, Secrets, manifests RBAC et le statut des déploiements.

Ce qu'il y a à l'intérieur : Architecture du projet

Le dépôt est organisé comme un espace de travail Cargo de 10 crates.

┌───────────────────────────────────────────────────────────────┐
│                       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           │   │
│  └──────────────────┘  └──────────────────────────────────┘   │
└───────────────────────────────────────────────────────────────┘

Chaque partie du cluster est responsable de son propre domaine de travail :

• api-server : Écrit avec le framework Axum. Gère l'API REST, l'API Watch via Server-Sent Events, les webhooks de validation et de mutation, l'évaluation des règles CEL et l'autorisation RBAC.
• scheduler : Sélectionne les nœuds pour les pods en fonction de l'affinité/anti-affinité, des taints, des tolérances et des contraintes de ressources.
• controller-manager : Contient 31 boucles de réconciliation. Gère Deployment, ReplicaSet, StatefulSet, DaemonSet, Job, CronJob, HPA, Ingress et les CRDs.
• kubelet : Communique avec Docker ou Podman via la crate bollard. Suit le cycle de vie des conteneurs, exécute les probes de liveness et readiness, et monte les volumes (hostPath, configMap, secret).
• kube-proxy : Gère les règles iptables pour les types de service ClusterIP, NodePort et LoadBalancer.

Comment exécuter pour les tests

La compilation nécessite un Rust récent, le compilateur protobuf et Docker ou Podman.

Le moyen le plus rapide de tester est le mode All-in-One avec SQLite :

cargo build -p rusternetes
./target/release/rusternetes --data-dir ./cluster.db

Si vous souhaitez démarrer une émulation plus honnête d'un environnement multi-composants via 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

Après le bootstrap, vous pouvez interagir avec le cluster en utilisant l'utilitaire standard kubectl.

Utilité pratique et conclusions

Intégrer Rusternetes en production maintenant n'en vaut pas la peine : bien que le projet passe 94% des tests e2e, il reste expérimental. Néanmoins, il a trois cas d'utilisation excellents.

Premièrement, c'est un guide d'étude idéal pour apprendre les rouages internes de Kubernetes. Lire du code source Rust avec une décomposition claire des modules est beaucoup plus agréable que de fouiller dans l'énorme monolithe du K8s original.

Deuxièmement, exécuter un cluster dans un seul processus avec SQLite économise des ressources sur les environnements de test et dans les pipelines CI/CD.

Troisièmement, le projet est utile pour exécuter l'orchestration sur du matériel faible comme le Raspberry Pi ou les plateformes IoT embarquées.

Si vous êtes intéressé par le développement de systèmes en Rust ou par le fonctionnement des orchestrateurs, le projet mérite définitivement une étoile sur GitHub.