eBPF: perguntando ao kernel o que está acontecendo

Por que tanta ferramenta nova de observabilidade, rede e segurança fala em eBPF? Porque ele permite rodar pequenos programas dentro do kernel Linux, com segurança, sem reiniciar nada e sem mexer na aplicação.

Fala pessoal, tudo bem?

Se você acompanha o ecossistema cloud native, já viu a sigla em todo canto: CNIs como o Cilium, ferramentas de segurança como Falco e Tetragon, perfis contínuos de CPU, monitoramento de rede. Quase tudo que é novo nessas áreas usa eBPF.

A ideia em uma imagem

ESPAÇO DE USUÁRIO Seu programa eBPF bpftrace, Cilium, Falco Resultado métricas, eventos, alertas KERNEL Verificador é seguro? termina? Anexado a um evento syscall, rede, função Mapas eBPF dados compartilhados Se o verificador não aprovar, o programa nem carrega. É isso que torna o eBPF seguro o bastante para rodar em produção.

Uma analogia: o eBPF é para o kernel o que o JavaScript foi para o navegador. Em vez de esperar a próxima versão para ganhar um recurso, você "programa" o comportamento dele em tempo real, numa área isolada.

Por que isso mudou a observabilidade

O jeito tradicional de observar uma aplicação é instrumentar: adicionar biblioteca, log, métrica, e fazer deploy. Com eBPF, dá para observar por fora, a partir do kernel, porque toda aplicação, em qualquer linguagem, acaba fazendo chamadas de sistema.

• Sem alterar código e sem reiniciar o serviço.
• Baixo custo: o programa roda dentro do kernel, sem copiar tudo para fora.
• Visão completa: todos os processos e containers da máquina, de uma vez.

Exemplo: experimentando com bpftrace

O bpftrace é o jeito mais fácil de sentir o poder do eBPF. No Debian/Ubuntu:

$ sudo apt install bpftrace

# quais arquivos cada processo está abrindo, em tempo real
$ sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat
    { printf("%-16s %s\n", comm, str(args->filename)); }'

# quais comandos estão sendo executados na máquina
$ sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve
    { printf("%-16s %s\n", comm, str(args->filename)); }'

# quem mais faz chamadas de sistema (Ctrl+C para ver o resumo)
$ sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'

Rode o segundo e, em outro terminal, faça um kubectl apply ou um apt update. Você vai ver cada processo que nasce, inclusive os que rodam dentro de containers.

💡 Ótimo para o lab: rode o exemplo de execve num node do seu cluster kind e crie um pod. Dá para ver o runtime de container, o pause container e a sua aplicação nascendo, um processo de cada vez.

Onde você já usa eBPF sem saber

Área	O que o eBPF faz
Rede no Kubernetes	Roteamento e políticas de rede sem depender de milhares de regras iptables
Segurança em runtime	Detectar shell aberto em container, leitura de arquivo sensível
Observabilidade	Latência de rede, perfil de CPU contínuo, métricas sem instrumentar
Systemd	Filtros de rede e de dispositivos por serviço

⚠️ Poder exige cuidado: carregar programas eBPF exige privilégio alto. Uma ferramenta eBPF mal-intencionada vê tudo o que acontece na máquina. Avalie bem o que você instala com esse nível de acesso.

Considerações Finais

O eBPF é uma das mudanças mais importantes do Linux nos últimos anos, e quase invisível para quem só usa as ferramentas. Não precisa virar especialista: entender o conceito e brincar com o bpftrace já muda a forma como você investiga problemas.

Na próxima vez que alguém disser "não dá para saber o que esse processo está fazendo", você vai saber que dá.

Abs e até a próxima!!!

:wq!

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!

Cron ou systemd timer? Repensando o agendamento de tarefas no Linux

O cron está aí desde os anos 70 e continua funcionando. Mas existe uma alternativa nativa em quase toda distribuição moderna que resolve problemas que o cron simplesmente ignora.

Fala pessoal, tudo bem?

No post "Backup simples com rsync", agendamos o script com o cron, às 2h da manhã. Funciona. Mas pense em algumas perguntas:

• E se o servidor estava desligado às 2h? O backup daquele dia simplesmente não acontece.
• O backup falhou? Você só descobre lendo o log, se lembrar de ler.
• Ele ainda estava rodando quando o próximo começou? O cron nem quer saber.

É aqui que entram os systemd timers.

Cron x systemd timer

	cron	systemd timer
Máquina desligada no horário	Execução perdida	Roda ao ligar (Persistent=true)
Logs	Por sua conta	Automático no journalctl
Execuções sobrepostas	Podem acontecer	Não sobrepõe o mesmo serviço
Próxima execução	Você calcula de cabeça	systemctl list-timers mostra
Limitar CPU/memória	Não	Sim, direto no service
Simplicidade	Uma linha 🏆	Dois arquivos

Como funciona: dois arquivos

backup.timer QUANDO rodar backup.service O QUE rodar backup.sh o seu script de sempre O script não muda. Muda só quem chama e quando.

Exemplo: migrando o backup do rsync

Primeiro o service, em /etc/systemd/system/backup.service:

[Unit]
Description=Backup diario com rsync

[Service]
Type=oneshot
User=usuario
ExecStart=/home/usuario/backup.sh
# não deixar o backup derrubar o resto do servidor
CPUQuota=50%
MemoryMax=512M
Nice=10

Depois o timer, em /etc/systemd/system/backup.timer:

[Unit]
Description=Agenda o backup diario

[Timer]
OnCalendar=*-*-* 02:00:00
# se estava desligado às 2h, roda assim que ligar
Persistent=true
# espalha em até 15 min (útil com muitos servidores)
RandomizedDelaySec=15min

[Install]
WantedBy=timers.target

Ativando e conferindo:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now backup.timer

# quando roda a próxima vez
$ systemctl list-timers backup.timer

# rodar agora, para testar
$ sudo systemctl start backup.service

# o que aconteceu na última execução
$ journalctl -u backup.service -n 50

💡 Não sabe escrever o OnCalendar? O próprio systemd valida e mostra as próximas execuções:
systemd-analyze calendar "Mon..Fri *-*-* 08:30:00" --iterations=3

⚠️ Lembrete do post do rsync: o service roda sem você logado, assim como o cron. A chave SSH do backup continua precisando funcionar sem passphrase e sem ssh-agent.

Então o cron morreu?

Não. Para uma tarefa simples, num servidor só, uma linha no crontab continua sendo ótima. O timer começa a valer a pena quando a tarefa é importante: quando falhar em silêncio custa caro, quando ela pode demorar, quando precisa de limite de recurso.

E de bônus: quem entende timers e services entende o systemd, que é quem de fato gerencia o seu servidor Linux.

Considerações Finais

A pergunta não é "cron ou systemd". É: se essa tarefa não rodar hoje, eu vou ficar sabendo? Se a resposta for não, vale trocar.

Abs e até a próxima!!!

:wq!

Linux 7.x: um kernel novo a cada dois meses. Preciso acompanhar?

O kernel Linux já está na série 7.x. Entender como ele é lançado e mantido ajuda a responder uma pergunta que todo sysadmin faz: qual kernel eu deveria rodar?

Fala pessoal, tudo bem?

Em agosto o Linus Torvalds lançou o Linux 7.2, no prazo, com novidades como Cache Aware Scheduling, melhorias de I/O em AMD e Intel e suporte inicial ao Apple M3. Logo em seguida abriu a janela do 7.3, que já aparece no Ubuntu 26.10.

E é sempre assim: um kernel novo a cada 9 ou 10 semanas. Dá vontade de perguntar se é preciso correr atrás de cada um.

Spoiler: o número "7" não significa nenhuma revolução. O Linus costuma trocar o primeiro número quando o segundo chega perto de 20, para, como ele mesmo brinca, não ficar sem dedos para contar. Não há quebra de compatibilidade por causa disso.

Como um kernel nasce

O ciclo de ~9 semanas Merge window 2 semanas rc1 ... rc7/rc8 só correções Lançamento ex: 7.2 Stable 7.2.1, 7.2.2... Algumas versões, uma por ano, viram LTS (longterm): recebem correções por anos, e são a base das distribuições corporativas. Tudo isso fica listado em kernel.org: mainline, stable e longterm.

Então, qual kernel eu rodo?

Para quase todo mundo que administra servidor, a resposta é: o kernel que a sua distribuição entrega.

Cenário	O que usar
Servidor de produção	Kernel da distro LTS (Debian, Ubuntu LTS, RHEL e derivados)
Hardware muito novo	Kernel mais recente oferecido pela distro (backports, HWE)
Desktop, laboratório, curiosidade	Distro interina ou rolling (Ubuntu 26.10, Fedora, Arch)
Compilar o próprio kernel	Só se você tiver um motivo muito específico

💡 Por que confiar na distro: as distribuições aplicam correções de segurança no kernel antigo (backport). Um 5.15 do Ubuntu atualizado pode ter correções que saíram ontem. O número da versão não conta a história toda.

Conhecendo o kernel que você roda

# versão em execução
$ uname -r

# kernels instalados (Debian/Ubuntu)
$ dpkg --list | grep linux-image

# o sistema está pedindo reboot depois de uma atualização?
$ ls /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs

# quanto tempo desde o último boot (e, portanto, do último kernel carregado)
$ uptime -p

⚠️ Uptime alto não é motivo de orgulho. Servidor ligado há 800 dias quase sempre significa kernel sem patch há 800 dias. Atualizar o pacote não adianta se o kernel antigo continua carregado na memória. Precisa reiniciar (ou usar livepatch, quando disponível).

Por que ainda vale acompanhar as novidades

Mesmo sem rodar o kernel mais novo, ler as notas de lançamento ajuda a entender para onde as coisas vão. Muito do que chega hoje no mainline aparece nas distros LTS em um ou dois anos: melhorias de escalonador, eBPF, Rust, sistemas de arquivos.

Um bom hábito: acompanhar só o resumo de cada versão (sites como LWN, Phoronix ou KernelNewbies fazem isso muito bem) e anotar o que pode ajudar no seu ambiente.

Considerações Finais

O kernel anda rápido de propósito: muitas mudanças pequenas são mais seguras que poucas mudanças enormes. Para quem opera servidores, o segredo não é correr atrás de cada versão, é manter o kernel da sua distro atualizado e, principalmente, reiniciar.

Abs e até a próxima!!!

:wq!

“WARNING: connection is not using a post-quantum key exchange”: o aviso novo do SSH

Computadores quânticos capazes de quebrar criptografia ainda não existem. Mas o SSH já começou a avisar quando a sua conexão não está protegida contra eles. Entenda por quê.

Fala pessoal, tudo bem?

No post "SSH sem dor de cabeça" configuramos chaves e atalhos para conectar nos nossos nodes. Se você atualizou o cliente SSH recentemente, pode ter dado de cara com isto:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html

Calma, ninguém invadiu o seu servidor. Mas o aviso merece atenção.

"Guarde agora, decifre depois"

A ideia por trás do aviso é simples e um pouco assustadora:

Hoje Atacante grava sua sessão SSH cifrada Anos depois Surge computador quântico capaz de quebrar a troca Resultado Senhas, segredos e comandos expostos O risco não é o atacante de hoje. É o tráfego de hoje nas mãos do atacante de amanhã.

Por isso a proteção precisa começar antes de o computador quântico existir. Um segredo que vale para os próximos 10 anos já está em risco hoje.

O que o OpenSSH mudou

• OpenSSH 9.0 (2022): passou a usar por padrão uma troca de chaves híbrida pós-quântica (sntrup761x25519).
• OpenSSH 10.0 (abril de 2025): o padrão virou mlkem768x25519-sha256, baseado no ML-KEM, padronizado pelo NIST.
• OpenSSH 10.1: o cliente passou a avisar quando a conexão não usa nenhum algoritmo pós-quântico.

"Híbrido" é a palavra-chave: o algoritmo combina o clássico X25519 com o pós-quântico ML-KEM. Se um dos dois tiver alguma fraqueza descoberta no futuro, o outro continua protegendo.

Como verificar a sua conexão

# versão do seu cliente
$ ssh -V

# algoritmos de troca de chave que o cliente conhece
$ ssh -Q kex | grep -E "mlkem|sntrup"

# qual algoritmo foi negociado com o servidor
$ ssh -v kub-node1 exit 2>&1 | grep "kex: algorithm"
debug1: kex: algorithm: mlkem768x25519-sha256

No servidor, confira se a configuração não está bloqueando os algoritmos novos:

# versão e algoritmos efetivamente ativos no sshd
$ sudo sshd -V
$ sudo sshd -T | grep -i kexalgorithms

⚠️ Armadilha comum: guias antigos de "hardening de SSH" mandam fixar uma lista de KexAlgorithms no sshd_config. Essa lista, feita anos atrás, provavelmente exclui os algoritmos pós-quânticos. Revise antes de culpar a versão.

E se o servidor não puder ser atualizado?

Switch, appliance, equipamento legado... acontece. Nesse caso dá para silenciar o aviso só para aquele host, assumindo o risco de forma consciente, no seu ~/.ssh/config:

Match host switch-legado.lab
    WarnWeakCrypto no-pq-kex

💡 Dica: nunca desligue o aviso globalmente. Ele é exatamente o que vai te lembrar de que aquele equipamento precisa sair da rede um dia.

Considerações Finais

A transição para criptografia pós-quântica é uma daquelas mudanças que acontecem em silêncio, por baixo das ferramentas que usamos todo dia. No SSH, a parte difícil já foi feita: basta estar atualizado e não atrapalhar com configuração antiga.

O aviso no terminal não é um problema. É um inventário gratuito dos servidores que ficaram para trás.

Abs e até a próxima!!!

:wq!

Kubernetes 1.37 “Garhwal”: o que vale prestar atenção (e a versão de que você precisa sair agora)

O Kubernetes lança uma versão a cada quatro meses. Não dá para acompanhar tudo, mas dá para saber o que importa e quando a sua versão vai ficar sem suporte.

Fala pessoal, tudo bem?

O Kubernetes 1.37, codinome "Garhwal", saiu no final de agosto e já está na 1.37.1. Foram 67 melhorias: 16 viraram estáveis, 23 chegaram ao beta e 27 entraram como alpha.

Ninguém precisa ler as 67. Vou separar o que chama atenção para quem opera cluster no dia a dia. E, mais importante, falar de suporte, que é onde muita gente se complica.

Destaques que valem um olhar

• Metrics API estável (GA): a API que alimenta o kubectl top e o HPA finalmente é considerada estável.
• HPA com scale to zero (beta): o autoscaler pode levar um deployment a zero réplicas. Ótimo para ambientes de teste e workloads que ficam ociosos.
• Kubelet em modo rootless (beta): o kubelet rodando dentro de um user namespace, reduzindo o estrago caso algo escape do container.
• Memory QoS (beta): proteção de memória em camadas usando cgroups v2.
• PVC "last used time" (beta): saber quando um volume foi usado pela última vez. Quem já caçou disco órfão na cloud sabe o valor disso.
• Pod Certificates: certificados emitidos para pods, facilitando mTLS entre serviços.

Repare no padrão: boa parte das novidades é sobre segurança (rootless, certificados) e eficiência (scale to zero, memória, volumes esquecidos). O Kubernetes está ficando mais maduro, não mais complicado.

Alpha, beta e GA: o que isso significa para você

Estágio	Ligado por padrão?	Usar em produção?
Alpha	Não	Não. Pode mudar ou sumir.
Beta	Depende da feature	Com cuidado e teste.
GA (stable)	Sim	Sim. A API não quebra mais.

A parte que ninguém gosta: ciclo de suporte

Cada versão menor do Kubernetes recebe correções por cerca de 14 meses. Depois disso, você está por conta própria. Veja a situação hoje:

Até quando cada versão recebe correções de segurança out/26 jan/27 abr/27 jul/27 out/27 1.34 acaba em 27/out/2026 1.35 fev/2027 1.36 jun/2027 1.37 out/2027

🚨 Se você está na 1.34: as correções de segurança terminam em 27 de outubro de 2026, daqui a poucos dias. A 1.33 e anteriores já estão sem suporte nenhum. Se você usa um serviço gerenciado (EKS, AKS, GKE), confira o calendário do provedor, que pode ser diferente.

Antes de atualizar: o mínimo que você deve checar

# versão do cliente e do cluster
$ kubectl version

# versão do kubelet em cada node
$ kubectl get nodes -o wide

# APIs depreciadas que ainda estão sendo chamadas
$ kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

💡 Regra prática: o Kubernetes só permite subir uma versão menor por vez no control plane (1.35 → 1.36 → 1.37). Quem fica muito para trás transforma uma atualização simples em um projeto de semanas.

Considerações Finais

Acompanhar o Kubernetes não é ler todo changelog. É ter duas informações sempre à mão: o que de novo resolve um problema seu, e quando a versão que você roda deixa de receber correções.

A primeira é opcional. A segunda, não.

Abs e até a próxima!!!

:wq!

O Ingress NGINX foi aposentado. E agora?

Fala pessoal, tudo bem?

"O controlador mais usado para expor aplicações no Kubernetes parou de receber atualizações em março de 2026. Se ele ainda está no seu cluster, você está sem patches de segurança."

Em novembro de 2025 o projeto Kubernetes anunciou algo que pegou muita gente de surpresa: o Ingress NGINX seria aposentado em março de 2026. Esse prazo já passou.

Estamos falando de um componente usado em cerca de metade dos ambientes cloud native, segundo o próprio comunicado do Kubernetes. E o motivo não foi técnico: foi falta de mantenedores.

🚨 O que significa na prática: sem novas versões, sem correção de bug e sem patch de segurança. O controlador continua rodando, mas qualquer vulnerabilidade nova fica aberta para sempre.

Obs: estamos falando do projeto comunitário kubernetes/ingress-nginx. O controlador mantido pela F5/NGINX é outro projeto.

Como saber se você usa

# quais IngressClasses existem no cluster
$ kubectl get ingressclass

# procurando o controlador comunitário em qualquer namespace
$ kubectl get pods -A -l app.kubernetes.io/name=ingress-nginx

# quantos Ingress dependem dele
$ kubectl get ingress -A

Se apareceu algo, o assunto é com você. Rode isso em todos os clusters, inclusive aquele de homologação esquecido.

A lição maior: infraestrutura crítica sem dono

Antes da parte técnica, vale a reflexão. Um componente que está na frente de metade das aplicações do mundo foi mantido por pouquíssimas pessoas, muitas no tempo livre. Quase ninguém que usava contribuía.

Isso não é exclusivo do Ingress NGINX. Pergunte-se: quantas peças do seu ambiente dependem de projetos que você nunca olhou quem mantém?

Para onde ir: Gateway API

A recomendação oficial é migrar para a Gateway API (ou para outro controlador Ingress mantido). A Gateway API é o sucessor do Ingress, e a maior mudança é a separação de responsabilidades:

Cada recurso tem um dono GatewayClass qual implementação usar Provedor de infraestrutura Gateway porta, TLS, quem pode se ligar Time de plataforma / operação HTTPRoute host, path, para qual Service Time da aplicação

No Ingress, tudo isso ficava num único objeto, cheio de annotations específicas do controlador. Na Gateway API, cada time mexe só no que é seu.

Exemplo: o mesmo roteamento, antes e depois

# ANTES: Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: loja
spec:
  ingressClassName: nginx
  rules:
    - host: loja.exemplo.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: loja-web
                port:
                  number: 80

# DEPOIS: HTTPRoute (o Gateway "publico" é do time de plataforma)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: loja
spec:
  parentRefs:
    - name: publico
      namespace: infra-gateway
  hostnames:
    - loja.exemplo.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: loja-web
          port: 80

💡 Atalho útil: o projeto ingress2gateway (kubernetes-sigs) converte Ingress existentes em recursos da Gateway API. Use como ponto de partida e revise o resultado. Annotations específicas do NGINX nem sempre têm equivalente direto.

Plano de migração em 4 passos

1. Inventário: liste todos os Ingress e, principalmente, as annotations usadas (rewrite, auth, rate limit).
2. Escolha a implementação da Gateway API e suba em paralelo, sem tirar o NGINX.
3. Migre por aplicação, começando pela menos crítica. Teste apontando DNS ou peso de tráfego.
4. Desligue o antigo só quando nenhum Ingress depender dele.

Considerações Finais

A aposentadoria do Ingress NGINX é um lembrete duro: open source é gratuito para usar, mas não é gratuito para manter. Alguém paga essa conta, e às vezes ninguém está pagando.

Se o seu cluster ainda depende dele, a migração não é mais "algum dia". É agora.

Abs e até a próxima!!!

:wq!