Migrar para o Envoy Gateway não é trocar YAML

Francisco das Chagas — Thu, 01 Oct 2026 22:48:32 +0000

O ingress-nginx não recebe patch de segurança desde março de 2026.
Ele continua funcionando, e é por isso que o risco passa despercebido.

A saída recomendada pelo próprio Kubernetes é a Gateway API, e o Envoy Gateway é uma das implementações dela. A tentação é tratar a migração como tradução: pegar cada anotação e reescrever no formato novo. Só que a migração não se resume a trocar YAML.

No nginx, cada app levava a própria regra de IP numa anotação. No Envoy, a regra sobe para uma SecurityPolicy no Gateway compartilhado. Ela muda de dono: sai do time da app e vai para a plataforma. Um erro, que antes afetava uma app, agora afeta todas as rotas.

Ela também muda de camada. A allowlist por IP é uma decisão de L3 tomada em L7. O proxy filtra o IP que ele acredita ser o do cliente. Se houver SNAT no caminho, todo mundo vira o IP do node. Se o X-Forwarded-For for aceito sem critério, qualquer um escreve o próprio IP.

Abaixo, os pontos que a documentação confirma e que eu teria errado se só traduzisse as anotações: SNAT, precedência por substituição, CIDR largo copiado e o API gateway que vira o único cliente.

Qual regra de acesso sumiu, ou abriu demais, numa migração que parecia só de ferramenta no seu ambiente?

Referências

Três ferramentas, nenhuma resposta

Francisco das Chagas — Thu, 01 Oct 2026 22:48:29 +0000

Hoje toda conversa de operação termina em "qual IA a gente coloca aqui?".

Vou começar esta série por outra pergunta: quantas das suas ferramentas você consegue provar que funcionam?

Nós tínhamos três. Logs numa, métricas em outra, APM numa terceira.

Quando alguma coisa quebrava, a resposta não estava em nenhuma delas.

Não faltava ferramenta. Faltava garantia:

a aplicação parava de mandar log para o cluster e ninguém percebia;
quando o log chegava, não trazia a informação necessária;
a retenção dependia de uma rotina de limpeza configurada à mão, e nem sempre funcionava: guardávamos meses de dados quando o combinado eram semanas.

Eram três lugares para procurar e nenhum dono. Em gestão de risco, isso tem nome: controle que só existe no papel. A auditoria marca "temos monitoramento", mas no dia do incidente ninguém confia nele.

A saída não foi comprar uma quarta ferramenta. Foi juntar logs, métricas e traces num lugar só (open source, com OpenTelemetry) e usar menos coisa, não mais.

Nos próximos posts, vou contar o que isso revelou, com números: o que funcionou, o que custou, onde a IA ajudou e onde errou.

Comece pela pergunta do início: das ferramentas de observabilidade que você paga hoje, quantas você já testou num incidente real?

DEV Community: Francisco das Chagas

Migrar para o Envoy Gateway não é trocar YAML

Referências

Três ferramentas, nenhuma resposta