Cilium 1.20: o Gateway API virou camada de tráfego completa — com duas pegadinhas pra testar antes

Em 14 de setembro de 2026 o Cilium lançou a versão 1.20, o segundo release maior do ano — mais de 2.660 commits, 1.100+ contribuidores. O destaque não é uma feature isolada: é o Gateway API do projeto saltando de v1.4 pra v1.6.1 numa tacada só, o que muda de vez o que dá pra fazer com um Gateway do Cilium sem sair do padrão upstream do Kubernetes.

Se você já usa Cilium como CNI e tem Gateway API habilitado (ou está cogitando substituir um Ingress Controller por ele), o release traz capacidade nova real. Mas duas delas têm ressalvas que vale testar antes de generalizar em produção — não é só “atualiza e usa”.

O que o salto de versão do Gateway API trouxe

Quatro capacidades novas, todas vindas do upstream do Gateway API e agora implementadas no Cilium:

ListenerSets — permitem que um time de aplicação anexe e gerencie os próprios listeners num Gateway compartilhado, sem precisar que o time de plataforma edite o Gateway principal a cada novo listener. Separa “quem é dono do Gateway” de “quem precisa expor uma porta nele”.
TCPRoute e UDPRoute — tráfego que não é HTTP (banco de dados, DNS, servidor de jogo, qualquer coisa em TCP/UDP puro) passa a caber no mesmo modelo de roteamento do Gateway API, em vez de precisar de um Service do tipo LoadBalancer à parte.
ExternalAuth — filtro de HTTPRoute que delega a decisão de autenticação/autorização a um serviço externo via protocolo ext_authz do Envoy (gRPC ou HTTP), antes da requisição chegar na aplicação. É a implementação do GEP-1494 do Gateway API.
CORS nativo e mais códigos de redirect (303, 307, 308) — resolve casos que antes exigiam EnvoyExtraConfig ou anotação específica do Cilium.

As três primeiras CRDs (TCPRoute, UDPRoute, ListenerSet) são opcionais: se você não instalar os CRDs correspondentes, o Cilium simplesmente desabilita o suporte àquela feature, sem quebrar o resto. Isso facilita adoção incremental — mas também significa que “atualizei o Cilium” não é o mesmo que “já tenho TCPRoute disponível”.

Pegadinha 1: TCPRoute/UDPRoute não combina com host network

O tráfego de TCPRoute e UDPRoute não passa pelo Envoy — ele vai direto pro Service que o Gateway gera, que normalmente expõe a porta do listener como LoadBalancer. Se o seu Gateway roda em modo host network, esse Service vira NodePort em vez de LoadBalancer, e a porta deixa de ser a que você configurou no listener — passa a ser uma porta aleatória da faixa de NodePort do cluster.

Na prática: se você depende de host network (comum em bare metal sem LoadBalancer de nuvem) e quer expor um Postgres ou um DNS via TCPRoute, a porta que chega no cliente não é a que está no manifesto. Vale conferir esse detalhe antes de apontar qualquer coisa em produção pra uma porta fixa.

Pegadinha 2: ExternalAuth com WireGuard cross-node — reportado, não confirmado por advisory

O ExternalAuth já apareceu em pré-release (v1.20.0-pre.3) e um operador documentou, em relato público (não é advisory oficial do projeto Cilium), um comportamento específico: em cluster com modo túnel + criptografia WireGuard habilitada, a sub-requisição ext_authz do Envoy pro backend de autenticação era descartada silenciosamente sempre que cruzava nó — sem log de política bloqueada, sem erro visível. A causa relatada: o tráfego de ext_authz sai do Envoy com identidade host/remote-node (encryptkey=0, sem criptografia), e não consegue ser entregue a um pod que espera tráfego criptografado (encryptkey=255) — um padrão parecido com o do CVE-2024-28250.

O mesmo relato registra que, ao subir para 1.20.1, o bloqueio nesse cenário específico deixou de ocorrer — mas o próprio autor deixou a validação completa do datapath como pendente. Ou seja: não é uma falha confirmada e corrigida via security advisory formal do Cilium, é um relato de campo. Dá pra tratar como sinal, não como veredito.

Se seu cluster combina os três ingredientes — ExternalAuth, modo túnel e WireGuard node-to-node —, vale rodar o cenário em staging com nós físicos separados (o problema só aparece cruzando nó) antes de confiar nisso pra autenticação em produção. Sem essa combinação específica, a feature não tem nenhum caveat documentado.

IPv6 no ENI IPAM (Beta) e migração de IPAM sem rebuild

Cilium 1.20 adiciona suporte a IPv6 no IPAM de ENI da AWS, em Beta. E separadamente — mas no mesmo tema de gestão de IP — chega um caminho de migração de cluster-pool pra multi-pool IPAM sem precisar reconstruir o cluster. Se você já cogitou migrar de IPAM mas parou no “vai exigir recriar tudo”, esse é o motivo pra reavaliar.

O que fica pra trás: Mutual Authentication (Beta)

O suporte a Mutual Authentication (Beta) — o mecanismo mTLS mais antigo do Cilium — foi marcado como deprecado nesta versão, com remoção prevista pra uma versão futura (a nota de release não fixa qual). A recomendação do próprio changelog é migrar para o Ztunnel Transparent Encryption (também Beta). Se você tem Mutual Authentication configurado hoje, não é urgente, mas é hora de colocar a migração no radar antes que vire remoção sem aviso maior.

Outros pontos de atenção no upgrade

Dependência de Kubernetes v1.36 e Envoy v1.37.x — confira a matriz de compatibilidade do seu cluster gerenciado antes de agendar o upgrade.
Caminho de upgrade e rollback testado é só entre versões minor consecutivas. Pular de 1.18 direto pra 1.20 não é o caminho validado — suba um minor de cada vez.
Binário do CNI caiu de ~77 MB pra 16 MB — bom pra quem tem initContainer com timeout apertado ou registry lento.
Além de Mutual Authentication, o changelog pede atenção redobrada pra quem usa extensões Go do Envoy, política Kafka-aware, a API cilium.io/v2alpha1 de CiliumNodeConfig, integração com libnetwork e configuração de CNI customizada — nenhum desses tem detalhe público além do aviso genérico “confira o guia de upgrade” no próprio release.

O que fazer

Se você já roda Gateway API no Cilium: o upgrade em si é direto, mas trate TCPRoute/UDPRoute e ExternalAuth como features novas a testar isoladamente, não como parte automática do “upgrade e segue”. Antes de generalizar:

Se for expor tráfego não-HTTP via TCPRoute/UDPRoute e o Gateway roda em host network — confirme a porta real que chega no cliente antes de apontar produção.
Se for adotar ExternalAuth e o cluster usa modo túnel + WireGuard node-to-node — valide em staging com nós físicos distintos antes de depender disso pra autorização.
Se você usa Mutual Authentication hoje — comece a avaliar o Ztunnel Transparent Encryption com calma, sem esperar o aviso de remoção.
Confirme a versão do Kubernetes do seu cluster contra a matriz de compatibilidade do 1.20 antes de agendar a janela.

Fora dessas combinações específicas, o resto do release — ListenerSets pra delegar listener sem soltar o Gateway principal, CORS nativo, binário menor — é ganho direto sem contrapartida conhecida até agora.