Kern: runtime rootless de containers com cold start de 3,5 ms

Proposta e funcionamento

O Kern é apresentado como um runtime de containers e sandbox sem daemon, executado sem privilégios e concentrado em um binário estático de 1,52 MB. A partir de uma imagem OCI, ele inicia um container real, com isolamento imposto pelo kernel, em cerca de 3,5 ms; um box sem imagem parte em aproximadamente 2,3 ms. O projeto também afirma consumir zero RAM quando está parado e ter apenas libc como dependência Rust no binário de lançamento.

Além de baixar, criar a partir de Dockerfiles, versionar, enviar, salvar e carregar imagens OCI, o Kern reúne isolamento, limitação de recursos e execução de pilhas. Usa namespaces de usuário, PID, montagem, rede, UTS e IPC, pivot_root, cgroup v2, raiz sobreposta ou somente leitura e uma lista de permissões seccomp. O perfil --security-profile untrusted combina a lista de permissões seccomp, remoção de todas as capacidades e sistema de arquivos somente leitura. O comando kern run aplica limites de CPU e memória a processos do host sem colocá-los em um sandbox; o Landlock pode restringir os caminhos em que esses processos escrevem.

Perfis declarados em kern.toml podem reservar CPU e memória (vcpu), disco temporário (vdisk) e dispositivos (vgpio) para boxes ou processos comuns. O projeto ressalva que, em modo rootless, um vdisk usa tmpfs, enquanto em modo privilegiado usa uma imagem ext4 em loop; ambos têm limite de tamanho. Já um dispositivo GPIO é concedido no nível do chip: selecionar pinos é apenas metadado cooperativo, não uma barreira por linha.

Compatibilidade e usos

O comando kern compose lê arquivos docker-compose.yml sem conversão e mantém a comunicação entre serviços por nome, mas não implementa a API do Docker. Não há redes sobrepostas, Swarm ou CRI, portanto a proposta é um fluxo de desenvolvimento local, não um orquestrador de produção nem um runtime de Kubernetes. Em um exemplo com PostgreSQL e Adminer, a camada web aquecida respondeu em cerca de 0,3 segundo e a pilha consumiu aproximadamente 66 MB, além de não haver daemon residente.

O projeto inclui comandos de inspeção e monitoramento, SDKs para Python e Node e um servidor MCP. O pacote kern-sandbox executa código em boxes novos por padrão, com rede desativada, limites de memória e processos, capacidades removidas, saída limitada e tempo máximo controlado pelo próprio vínculo. Falhas como tempo esgotado, falta de memória ou chamada de sistema bloqueada retornam como dados. Um modo persistente e um kernel aquecido reduzem a latência, mas oferecem isolamento mais fraco. O servidor MCP expõe execução de Python, Bash e Node, além de leitura, escrita e listagem de arquivos.

Desempenho, segurança e estágio

Nos testes publicados em um Intel i7-14700KF, 200 boxes foram iniciados em cerca de 0,11 segundo, contra 44,8 segundos no Podman e 16,2 segundos no Docker; três mil boxes levaram aproximadamente 2,2 segundos, e cada box ativo consumiu cerca de 0,3 MB. O projeto observa que a latência individual próxima de 1 a 2 ms de unshare e exec fica sujeita ao ruído de medição e que o bubblewrap, usado na comparação, não oferece imagens, capacidades ou ciclo de vida.

O limite de segurança é o próprio kernel Linux: uma vulnerabilidade de escalação de privilégios no kernel poderia permitir escape, e o uso de user namespaces mantém essa classe de risco. Montar diretórios do host, usar --net host ou habilitar --privileged são decisões de confiança do usuário, não fronteiras impostas pelo Kern. Por isso, o projeto diz que seu alvo são códigos próprios, gerados por agentes, tarefas de CI e etapas de build, não código hostil de terceiros em ambientes multiusuário. O Kern requer namespaces de usuário sem privilégios e cgroup v2, roda em Linux, WSL2 e algumas placas ARM, e não tem compilação nativa para Windows.

A versão 0.7.0 é a primeira publicação. O núcleo é declarado concluído, com 848 testes em Rust, 78 em Python e 61 em Node, além de execução validada em Linux, WSL2, Raspberry Pi 5, Jetson Orin Nano e Arduino UNO Q. A documentação mantém uma lista explícita de itens pendentes, incluindo suporte a GPU, que ainda está no roteiro.