A conta da cloud também é um problema de engenharia

Pedir 4 CPUs "por garantia" parece inofensivo. Multiplique por 200 pods, 24 horas por dia, 30 dias por mês. Uma reflexão sobre custo como requisito de engenharia, e não só problema do financeiro.

Fala pessoal, tudo bem?

Durante muito tempo, custo de infraestrutura era assunto de compras. O servidor era comprado, depreciado em alguns anos, e pronto. Na cloud, a lógica inverteu: cada decisão técnica vira uma linha na fatura, todo mês, para sempre.

Um requests exagerado, um ambiente de teste que ninguém desligou, um disco órfão de um cluster apagado em 2024. Nenhum deles chama atenção sozinho. Juntos, viram a conversa desconfortável do fim do trimestre.

FinOps, em uma frase: trazer o custo para perto de quem toma as decisões técnicas, para que ele seja considerado na hora de decidir, e não só na hora de pagar.

Onde o dinheiro costuma vazar

Exemplo ilustrativo: CPU de um cluster Capacidade dos nodes 100% Reservado (requests) 80% Usado de verdade 25% Pago, reservado e parado O scheduler respeita o requests, não o uso. Node "cheio" de requests sobe outro node, e outra fatura.

Os suspeitos de sempre:

• Requests superdimensionados, copiados de um exemplo ou definidos "por segurança".
• Ambientes não produtivos ligados 24/7, inclusive fins de semana.
• Recursos órfãos: discos, IPs públicos, snapshots e load balancers que sobraram.
• Logs e métricas sem retenção definida, crescendo para sempre.
• Tráfego entre zonas e regiões, que quase ninguém olha até a fatura chegar.

Exemplo: comparando o pedido com o uso

# o que cada pod está USANDO agora
$ kubectl top pods -n app-pagamentos

# o que cada pod está PEDINDO
$ kubectl get pods -n app-pagamentos -o custom-columns=\
POD:.metadata.name,\
CPU_REQ:.spec.containers[*].resources.requests.cpu,\
MEM_REQ:.spec.containers[*].resources.requests.memory

# o quanto cada node já está reservado
$ kubectl describe nodes | grep -A 5 "Allocated resources"

Se o pod pede 2 de CPU e usa 150m o dia inteiro, você encontrou dinheiro parado. Olhe em uma janela de dias, não de minutos, para não cortar o que é pico real.

💡 Novidade que ajuda: o Kubernetes 1.37 trouxe em beta o scale to zero no HPA e o "last used time" em PVCs. O primeiro desliga o que está ocioso; o segundo ajuda a achar volume esquecido.

Custo como mais um sinal de qualidade

No SRE falamos de latência, erro, tráfego e saturação. Vale incluir um quinto olhar: quanto custa servir cada requisição. Uma mudança que deixa o serviço 5% mais rápido e 300% mais caro talvez não seja uma melhoria.

Prática	Esforço	Impacto típico
Desligar ambientes de teste fora do horário	Baixo	Alto
Etiquetar recursos por time e projeto	Baixo	Alto (visibilidade)
Revisar requests pelo uso real	Médio	Alto
Política de retenção de logs	Baixo	Médio
Instâncias spot/preemptivas para lotes	Médio	Alto

⚠️ Cuidado com o corte cego: reduzir request até o pod começar a sofrer throttling ou OOMKilled não é economia, é incidente adiado. Custo é um sinal a equilibrar com confiabilidade, não a única meta.

Considerações Finais

FinOps não é sobre gastar menos a qualquer custo. É sobre gastar de propósito: saber quanto cada coisa custa, quem é dono dela e se ela ainda precisa existir.

E a melhor parte: quase sempre o primeiro passo não exige ferramenta nenhuma. Exige olhar.

Abs e até a próxima!!!

:wq!

Você sabe o que está rodando dentro da sua imagem? Cadeia de suprimentos de software

Seu código pode ter 2 mil linhas. A imagem que vai para produção pode ter centenas de pacotes que ninguém do time escolheu. Uma reflexão sobre confiança em tudo aquilo que você não escreveu.

Fala pessoal, tudo bem?

Em março de 2024 um engenheiro da Microsoft percebeu que o login por SSH estava cerca de meio segundo mais lento que o normal. Curioso, foi investigar. Encontrou uma backdoor no xz, uma biblioteca de compressão presente em praticamente toda distribuição Linux.

O atacante passou cerca de dois anos ganhando a confiança do mantenedor do projeto até conseguir publicar versões com código malicioso. Por pouco aquilo não chegou às versões estáveis das grandes distros.

A lição: o ataque não foi no código da empresa. Foi em uma dependência da dependência, mantida por uma pessoa só, no tempo livre. Isso é cadeia de suprimentos de software.

O iceberg da sua aplicação

Seu código Bibliotecas que você declarou Dependências transitivas Imagem base: SO, libc, openssl, xz... O que você revisa O que vai junto para produção

Exemplo: olhando por baixo d'água

Duas ferramentas abertas ajudam a responder "o que tem aqui dentro?". O syft gera a lista de componentes (o SBOM, a "lista de ingredientes"). O grype ou o trivy cruzam essa lista com vulnerabilidades conhecidas.

# quantos pacotes existem na imagem?
$ syft nginx:latest -q | wc -l

# gerar o SBOM em formato padrão (SPDX)
$ syft nginx:latest -o spdx-json > sbom-nginx.json

# vulnerabilidades conhecidas, só as graves
$ trivy image --severity HIGH,CRITICAL nginx:latest

Faça o teste com a imagem que o seu time usa em produção. O número costuma assustar na primeira vez.

💡 Menos é mais seguro: imagens mínimas (distroless, slim, alpine) têm muito menos pacotes. Menos pacotes significa menos coisa para atualizar, menos CVE no relatório e menos ferramentas à disposição de um invasor.

Quatro hábitos que reduzem o risco

1. Fixe versões. FROM nginx:latest muda sem avisar. Use uma tag específica ou, melhor ainda, o digest (nginx@sha256:...).
2. Escaneie na pipeline, não só uma vez. Uma imagem limpa hoje pode ter CVE crítica amanhã.
3. Gere e guarde o SBOM de cada versão publicada. Quando sair a próxima "xz", você responde em minutos se foi afetado.
4. Atualize a imagem base com frequência, mesmo sem mudança no código. Rebuild também é manutenção.

# exemplo de etapa no GitHub Actions: falha o build se houver CVE crítica
- name: Scan da imagem
  run: |
    trivy image --exit-code 1 --severity CRITICAL \
      --ignore-unfixed minha-app:${{ github.sha }}

⚠️ Cuidado com a fadiga de alerta: um relatório com 300 CVEs é ignorado. Comece bloqueando só o crítico com correção disponível (--ignore-unfixed) e vá apertando. Mesma lógica de alertas do SRE: alerta que ninguém age é ruído.

Considerações Finais

Ninguém consegue revisar todo o código que roda em produção. Mas dá para saber o que está lá, reduzir o que não precisa estar e reagir rápido quando algo for descoberto.

E, como vimos no caso do Ingress NGINX, vale lembrar: muitas peças críticas são mantidas por pouquíssimas pessoas. Contribuir, patrocinar ou ao menos conhecer quem mantém o que você usa também é segurança.

Abs e até a próxima!!!

:wq!

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!