Container não existe: o que o Linux faz por baixo do Docker e do Kubernetes

Não existe um objeto chamado "container" dentro do kernel Linux. Existe um processo comum, com uma visão limitada do sistema e um teto de recursos. Entender isso muda a forma como você investiga problemas.

Fala pessoal, tudo bem?

Na série Kubernetes do Zero subimos clusters, pods e até um "mini cluster" com o kind, onde cada node é... um container. Mas o que é um container, afinal?

A resposta que mais ajuda no dia a dia é esta:

Um container é um processo Linux com três coisas a mais: namespaces (o que ele enxerga), cgroups (quanto ele pode usar) e um sistema de arquivos próprio (a imagem). O resto é ferramenta em volta.

Kernel Linux do host (um só, compartilhado) "Container" Namespaces o que ele VÊ PID, rede, mount, hostname, usuários cgroups quanto ele USA CPU, memória, I/O, nº de processos Imagem o que ele TEM camadas montadas como raiz (/) Não há uma VM aqui: todos os containers usam o mesmo kernel.

Prova 1: o processo está ali, no host

Suba um container e procure ele com o ps do próprio host:

$ docker run -d --name teste nginx
$ ps aux | grep "nginx: master"
root   48213  0.0  0.1  ...  nginx: master process nginx -g daemon off;

# dentro do container, o mesmo processo acha que é o PID 1
$ docker exec teste cat /proc/1/cmdline; echo
nginx: master process nginx -g daemon off;

Mesmo processo, dois números de PID. Isso é o namespace de PID funcionando.

Prova 2: criando um "container" sem Docker

O comando unshare, que já vem no Linux, cria namespaces na mão:

# novo namespace de PID e de hostname
$ sudo unshare --pid --uts --fork --mount-proc bash

# agora, dentro dele:
# hostname meu-container
# ps aux
USER   PID  ...  COMMAND
root     1  ...  bash
root     8  ...  ps aux

Só dois processos visíveis, um hostname próprio. Sem imagem, sem daemon. É basicamente o que o Docker faz, com muito mais cuidado.

Prova 3: o limite de memória é um arquivo

$ docker run -d --name limitado --memory=256m nginx

# o limite está escrito no cgroup (v2) do container
$ docker exec limitado cat /sys/fs/cgroup/memory.max
268435456

# e todos os namespaces do sistema podem ser listados
$ sudo lsns

💡 No Kubernetes é igual: o resources.limits.memory do seu pod vira exatamente esse memory.max. Quando o pod passa do limite, quem mata o processo é o kernel (o famoso OOMKilled), não o Kubernetes.

Por que isso importa na prática

• Debug: ferramentas do host (ps, top, strace, nsenter) funcionam em containers, porque eles são processos.
• OOMKilled: deixa de ser mistério quando você sabe que é o cgroup de memória chegando no teto.
• Segurança: todos compartilham o mesmo kernel. Uma falha nele afeta todos os containers da máquina.

⚠️ Container não é VM. O isolamento é bom, mas não é o mesmo de uma máquina virtual. Container rodando como root e com --privileged está a poucos passos do host. Por isso o Kubernetes 1.37 está avançando com o kubelet em modo rootless.

Considerações Finais

Docker, containerd e Kubernetes são excelentes ferramentas, mas todas se apoiam em recursos que o kernel Linux oferece há anos. Quando algo estranho acontece com um container, lembre: no fundo, é só um processo. E processo Linux a gente sabe investigar.

Abs e até a próxima!!!

:wq!