Cilium 1.20: adote a evolução da rede sem tratar todo recurso novo como estável

O Cilium 1.20 amplia o suporte à Gateway API 1.6, incluindo ExternalAuth, ListenerSets, CORS, TCPRoute e UDPRoute.[9] A mesma atualização traz extensões do datapath e avanços no ztunnel, mas esses dois mecanismos continuam em beta.[9] O cuidado de engenharia é não colocar tudo no mesmo pacote de maturidade só porque chegou na mesma versão.

O que muda para quem desenvolve

ExternalAuth permite consultar autorização externa antes de encaminhar a requisição, enquanto ListenerSets permitem que equipes adicionem listeners a partir de seus namespaces sob controle da plataforma.[9] TCPRoute e UDPRoute ampliam a gestão de tráfego além de HTTP e gRPC.[9] Isso oferece uma oportunidade de revisar contratos entre aplicações e rede, em vez de continuar acumulando configurações isoladas.

Os plugins de datapath conectam processos separados por um recurso customizado e uma interface gRPC.[9] A documentação citada alerta que eles exigem conhecimento profundo dos internos do Cilium, podem quebrar o funcionamento ou enfraquecer a segurança e podem precisar de adaptação entre mudanças da arquitetura interna.[9] Não são uma extensão genérica de baixo risco.

Minha recomendação é avaliar separadamente três decisões: atualizar a plataforma, usar as novas rotas e introduzir componentes experimentais. Amarrar tudo a uma única mudança dificulta saber qual hipótese falhou.

Como aplicar

Monte uma matriz de tráfego antes do upgrade: HTTP autenticado, requisição rejeitada, TCP, UDP e comunicação entre pods. Para cada fluxo, registre origem, destino, política esperada e evidência de sucesso ou bloqueio.

Em homologação, valide primeiro o comportamento existente. Depois, experimente uma rota nova e uma integração de autorização externa. Defina explicitamente o resultado esperado quando o serviço de autorização estiver indisponível e verifique o comportamento real.

Caso avalie mTLS sem sidecar, isole o experimento do upgrade principal. Teste início da conexão, comunicação entre nós e no mesmo nó, falhas de identidade e visibilidade dos erros. O objetivo não é apenas obter tráfego criptografado, mas conseguir explicar falhas sem adivinhação.

Cuidados e limites

A opção bpf.datapathMode=auto escolhe netkit quando suportado e recua para veth nos demais nós; netkit exige Linux 6.8 ou superior.[9] O padrão permanece veth, sem mudança de comportamento sem adesão explícita.[9]

O ztunnel usa TLS 1.3 sobre HBONE, oferece autoridade interna ou identidades SPIRE e continua em beta; a antiga funcionalidade Mutual Authentication foi depreciada.[9] Quem usa autenticação antiga deve revisar as notas de migração, assim como usuários de políticas específicas de Kafka, extensões Go do Envoy e configurações CNI personalizadas.[9]

O ganho de uniformidade é relevante, mas não justifica ativar toda novidade de uma vez. A decisão madura separa o que simplifica a operação agora do que ainda exige assumir risco experimental.

Fonte

[9] Fonte: InfoQ