Reescrevendo o Kubernetes do Zero em Rust: Um Olhar no Projeto Rusternetes
Piadas sobre programadores de sistemas tentarem reescrever tudo em Rust já se tornaram um tropo clássico. Geralmente, esses empreendimentos terminam no estágio de "Hello World" ou na análise de configurações básicas. Mas com o Rusternetes, a história foi completamente diferente. O autor do projeto foi atrás do próprio Kubernetes e o reescreveu do zero.
Este não é um wrapper em torno de código Go ou um mock de teste simplificado. O repositório contém um plano de controle e componentes de nó completos: API server, scheduler, controller manager, kubelet e kube-proxy. Tudo escrito em Rust sem dependências Go de terceiros.
O projeto contém mais de 216.000 linhas de código, distribuídas em 10 crates, 31 controllers e mais de 3.100 testes unitários. Os desenvolvedores verificam a compatibilidade usando a suite oficial de testes e2e do Kubernetes (v1.35) via Sonobuoy. Atualmente, o Rusternetes passa com sucesso em 94% dos testes de conformidade (415 de 441).
Por Que Outro Kubernetes
O Kubernetes original é escrito em Go e requer recursos consideráveis. Para subir até mesmo um cluster local mínimo como minikube ou k3s, você precisa alocar uma máquina virtual ou executar vários containers pesados com o etcd.
O Rusternetes resolve esse problema com opções flexíveis de implantação. Ele possui três modos de operação:
- Cluster clássico com etcd. Todos os componentes são executados em containers separados e se comunicam com um cluster etcd.
- Substituir etcd por SQLite ou Redis. Em vez do etcd, o Rhino é conectado—um servidor gRPC compatível com etcd escrito em Rust. As configurações da API e os binários permanecem os mesmos; apenas o arquivo compose muda.
- Todos os componentes em um único binário. API server, scheduler, controller manager, kubelet e kube-proxy são executados como tarefas async do Tokio dentro de um único processo. O estado do cluster é gravado em um único arquivo SQLite ou instância Redis.
O modo All-in-One resolve os pontos problemáticos do desenvolvimento local, pipelines de CI/CD e execução do orquestrador em dispositivos de borda (Edge/IoT), onde cada megabyte de RAM conta.
Interface Web Integrada
O Rusternetes possui um dashboard de monitoramento integrado. Ele está embutido diretamente no binário do API server, então nada extra precisa ser configurado ou implantado.
A interface mostra um mapa de topologia do cluster com animação de tráfego, um heatmap de carga de CPU e RAM, streaming de logs de containers, e permite visualizar ConfigMaps, Secrets, manifestos RBAC e status de deployments.
O Que Tem Dentro: Arquitetura do Projeto
O repositório é organizado como um workspace 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 │ │
│ └──────────────────┘ └──────────────────────────────────┘ │
└───────────────────────────────────────────────────────────────┘
Cada parte do cluster é responsável por sua própria área de trabalho:
- api-server: Escrito usando o framework Axum. Manipula REST API, Watch API via Server-Sent Events, webhooks de validação e mutação, avaliação de regras CEL e autorização RBAC.
- scheduler: Seleciona nós para pods com base em afinidade/anti-afinidade, taints, tolerations e restrições de recursos.
- controller-manager: Contém 31 loops de reconciliação. Manipula Deployment, ReplicaSet, StatefulSet, DaemonSet, Job, CronJob, HPA, Ingress e CRDs.
- kubelet: Se comunica com Docker ou Podman via a crate
bollard. Rastreia ciclo de vida dos containers, executa probes de liveness e readiness e monta volumes (hostPath, configMap, secret). - kube-proxy: Gerencia regras de iptables para os tipos de serviço ClusterIP, NodePort e LoadBalancer.
Como Executar para Testes
A construção requer uma versão recente do Rust, o compilador protobuf e Docker ou Podman.
A forma mais rápida de testar é o modo All-in-One com SQLite:
cargo build -p rusternetes
./target/release/rusternetes --data-dir ./cluster.db
Se você quiser subir uma emulação mais honesta de um ambiente multi-componente 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
Após o bootstrap, você pode interagir com o cluster usando o utilitário padrão kubectl.
Utilidade Prática e Conclusões
Colocar o Rusternetes em produção agora não vale a pena: embora o projeto passe em 94% dos testes e2e, ele permanece experimental. No entanto, ele possui três casos de uso excelentes.
Primeiro, é um guia de estudo ideal para aprender os detalhes internos do Kubernetes. Ler código fonte em Rust com uma divisão clara de módulos é muito mais agradável do que vasculhar o grande monólito do K8s original.
Segundo, executar um cluster em um único processo com SQLite economiza recursos em ambientes de teste e em CI/CD.
Terceiro, o projeto é útil para executar orquestração em hardware fraco como Raspberry Pi ou plataformas IoT embarcadas.
Se você está interessado em desenvolvimento de sistemas em Rust ou em como orquestradores funcionam, o projeto definitivamente merece uma estrela no GitHub.
Projetos relacionados