Programação de sistemas Linux em Go: o nível baixo que sustenta o CNCF

Boa parte da infraestrutura que roda em produção hoje é escrita em Go, e não por acaso. Kubernetes, containerd, Cilium e Prometheus mostram que a linguagem virou padrão de fato para programar Linux em nível de sistema. Um workshop de meio período agendado para a GopherCon 2026, conduzido por Vladimir Vivien (Starkite.AI), se propõe justamente a explorar esse território menos glamouroso: como um programa Go fala diretamente com o kernel, sem esconder a complexidade atrás de bibliotecas de alto nível.

A descrição oficial na agenda do evento lista o roteiro técnico. Vale destrinchar cada peça, porque cada uma carrega um trade-off que raramente aparece em tutorial de API REST.

O pacote unsafe e a fronteira com o C

O kernel Linux fala C. Suas structs têm layout de memória específico, com alinhamento e padding que o Go não conhece por padrão. Para traduzir uma struct do kernel em Go, o caminho passa por unsafe.Pointer e por conversões que ignoram o sistema de tipos. É poderoso e perigoso na mesma medida: o compilador para de proteger você, e um offset errado vira corrupção silenciosa de memória.

O pré-requisito do workshop pede familiaridade com CGo, o que faz sentido. Boa parte da programação de sistema em Go vive nessa zona híbrida entre o runtime gerenciado e o mundo sem coletor de lixo. Quando não usar: se a syscall ou o pacote golang.org/x/sys/unix já expõem o que você precisa de forma tipada, recorrer a unsafe só adiciona risco sem ganho.

ioctl: controlando dispositivos

ioctl é a chamada de sistema coringa para configurar dispositivos: da placa de rede ao terminal, passando por GPIO em placas embarcadas. O problema clássico é montar o número mágico do comando (request) corretamente, respeitando as macros _IOR, _IOW e _IOWR do kernel. Em Go isso costuma virar constantes calculadas na mão ou geradas, e um bit trocado devolve EINVAL sem explicação. A promessa do workshop de mostrar como "construir ioctl adequadamente" ataca exatamente esse ponto de fricção.

mmap e zero-copy

Mapear memória com mmap permite acessar dados sem copiá-los entre kernel e user space. Para pipelines de alto throughput (logs, telemetria, IPC), evitar cópias reduz latência e pressão sobre o GC. O custo: você passa a lidar com páginas de memória fora do controle do runtime, precisa gerenciar o ciclo de vida do mapeamento manualmente e cuidar da sincronização. É otimização de caso específico, não default.

Containers na unha: namespaces e cgroups

O trecho mais didático talvez seja lançar processos containerizados diretamente do programa Go, usando namespaces e cgroups. É desmontar a mágica: um container não é uma entidade do kernel, e sim a combinação de isolamento (namespaces) com limites de recurso (cgroups) aplicados a um processo. Entender isso na fonte ajuda a debugar Docker, Kubernetes ou qualquer runtime OCI quando algo dá errado, em vez de tratá-los como caixa-preta.

Por que isso importa

O valor de aprender esse nível não é reescrever o containerd em casa. É ganhar modelo mental para os momentos em que a abstração vaza: um EPERM inexplicável, um container que não respeita o limite de memória, uma latência estranha num serviço que faz muita syscall. Quem entende a camada de baixo depura mais rápido e escolhe melhor quando não descer até ela.

Um alerta honesto: este tipo de código é intrinsecamente acoplado ao Linux e frequentemente à arquitetura. A recomendação do próprio workshop de ter uma máquina Linux (ou WSL2) e pacotes como linux-libc-dev, strace e dwarves deixa claro que cross-compilar não substitui rodar de verdade. Portabilidade sai pela janela, e isso é aceitável desde que seja decisão consciente.

Para quem quiser se preparar, o pacote golang.org/x/sys/unix é o ponto de partida oficial, e o strace continua sendo a melhor lente para ver o que um binário Go realmente pede ao kernel. A palestra está marcada para 4 de agosto de 2026 na GopherCon, com ingresso separado; a agenda oficial traz os detalhes de local e horário.

Fonte: Agenda oficial — Meeting Room 438, Level 4, SCC | Summit