Esta semana em cloud (03–09/ago): o L4 virou padrão; o resto da rede virou contrato

Q: O K8gb substitui o Traffic Manager ou o Route 53 para failover entre regiões?

Ele resolve o mesmo problema por um caminho diferente. O K8gb faz Global Server Load Balancing usando o que já existe no cluster — APIs padrão do Kubernetes, CoreDNS e external-dns — em vez de um serviço gerenciado do provedor. Isso significa que a lógica de failover entre clusters e regiões fica declarada nos seus manifestos e viaja com eles, sem reescrita quando o destino muda. O tradeoff é honesto: serviço gerenciado transfere a operação do plano de DNS para o provedor, enquanto o K8gb devolve essa responsabilidade para o seu time. A promoção a projeto incubado da CNCF, anunciada nesta semana, é o sinal que faltava para quem exigia maturidade formal antes de adotar — o projeto está no ecossistema desde o sandbox, em março de 2021, e tem adoção declarada em serviços financeiros, incluindo o banco português Millennium bcp.

Q: O Oracle Interconnect for AWS já serve para uma empresa brasileira?

Ainda não em produção, e o motivo é geografia. A disponibilidade geral começou no par OCI Ashburn e AWS US East (N. Virginia), com outros pares de região previstos para os próximos meses. Enquanto São Paulo não entrar nessa lista, o desenho para o Brasil continua sendo conectividade própria ou parceiro de trânsito, com a latência transatlântica inviabilizando qualquer tráfego sensível a tempo de resposta. O que vale acompanhar agora é o modelo comercial, porque ele muda a conta do multicloud: cobrança pela capacidade de conexão provisionada, sem taxa de transferência de dados, com suporte coordenado entre os dois provedores. Egress entre nuvens é justamente a linha que costuma inviabilizar arquitetura distribuída no orçamento. Se o padrão pegar, a pergunta deixa de ser quanto custa sair e passa a ser quanto custa manter o link.

Q: Faz sentido trocar meu NVA em VM pelo routing appliance do Azure?

Depende de qual dos dois papéis a sua VM está exercendo. O Azure Virtual Network routing appliance entrou em GA como serviço gerenciado de roteamento entre VNets, com plano de dados em hardware dedicado — a proposta é latência menor e throughput mais previsível que um roteador em software, sem o trabalho de patch e escala da VM. O que ele não faz é inspeção: firewall de aplicação, DPI e filtragem continuam com Azure Firewall, NSG ou o seu appliance de segurança. Se a VM só encaminha pacote, a troca tende a compensar em volume alto de tráfego. Se ela inspeciona, o appliance no máximo tira o roteamento do caminho dela. Em qualquer cenário, confirme a disponibilidade em Brazil South antes de desenhar a migração — recurso em GA no anúncio raramente está em GA em todas as regiões no mesmo dia.

Banner - Esta semana em cloud (03–09/ago): o L4 virou padrão; o resto da rede virou contrato

TL;DR — O Gateway API v1.6 promoveu TCPRoute e UDPRoute ao canal Standard, e a CNCF aceitou o K8gb como projeto incubado — duas peças que tornam roteamento L4 e balanceamento global portáveis entre clusters. Na mesma semana, Oracle e Microsoft entregaram a via contratual: Interconnect for AWS em GA, routing appliance em GA, Private Link sobre IPv6 em preview. A rede saiu do rodapé do diagrama; onde você a resolve define seu lock-in.

A semana passada foi sobre o que o Kubernetes vai remover do seu cluster. Esta foi sobre onde você vai resolver a sua rede — e as duas respostas possíveis chegaram com três dias de diferença.

Na segunda-feira, o projeto Kubernetes publicou o Gateway API v1.6. Na quarta, a CNCF anunciou o K8gb como projeto incubado. Entre uma coisa e outra, Oracle colocou o Interconnect for AWS em disponibilidade geral e a Microsoft empilhou quatro anúncios de rede: routing appliance em GA, Private Link sobre IPv6 em preview, ExpressRoute resiliency guard em preview e Azure DNS integrado ao Traffic Manager.

Ler isso como "muita novidade de networking" perde o ponto. São duas apostas concorrentes sobre onde a conectividade deve morar: no padrão que você carrega entre nuvens, ou no contrato que você assina com uma delas.

O que muda com TCPRoute e UDPRoute no canal Standard?

Até agora, expor tráfego não-HTTP no Kubernetes de forma declarativa era terreno de anotação proprietária. Cada controller tinha o seu jeito de dizer "escute na porta 5432 e mande para este Service", e esse jeito não sobrevivia à troca de implementação.

O v1.6 fecha essa lacuna: TCPRoute e UDPRoute saíram do canal Experimental para o Standard e passaram para a versão v1 da API. A v1alpha2 foi deprecada e será removida numa versão futura — quem já usava os recursos em experimental tem migração de apiVersion no radar, não reescrita.

O efeito prático é o mesmo que o HTTPRoute trouxe para a camada 7: uma forma portátil de descrever roteamento L4 por protocolo e porta, sem qualquer consciência de HTTP no caminho.

apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: postgres-primary
spec:
  parentRefs:
    - name: example-gateway
      sectionName: postgres
  rules:
    - backendRefs:
        - name: postgres-svc
          port: 5432

Isso importa para uma lista de workloads que sempre ficou de fora da conversa de ingress: bancos de dados, DNS, VoIP, MQTT e qualquer protocolo binário de indústria. São exatamente as cargas que, no Brasil, costumam ser a razão pela qual metade do tráfego ainda entra no cluster por um Service do tipo LoadBalancer com configuração feita à mão no console.

A segunda mudança do v1.6 é de governança e vai render mais no dia a dia do que parece: recursos experimentais migraram para um grupo de API separado, gateway.networking.x-k8s.io, com prefixo X no nome — o primeiro deles é o XBackend, voltado a egress. A fronteira entre estável e experimental deixou de ser conhecimento tribal e virou algo que dá para escrever numa policy de admissão.

Quem acompanha a transição desde a descontinuação do ingress-nginx já conhece o desenho geral — tratamos disso em Gateway API: o substituto do Nginx Ingress. A novidade é que a promessa de portabilidade agora cobre também o L4.

Por que o K8gb na CNCF importa mais do que parece?

Dois dias depois, a CNCF anunciou que o K8gb passou de sandbox a projeto incubado. É Global Server Load Balancing nativo de Kubernetes: distribuição de tráfego e failover automático entre clusters em regiões diferentes, montado sobre APIs padrão do Kubernetes, CoreDNS e external-dns.

A parte relevante é o que ele não exige. Não há serviço gerenciado de DNS global no caminho crítico, não há console de provedor onde a regra de failover mora fora do seu repositório. A intenção de resiliência fica declarada como recurso do cluster e viaja junto com o resto dos manifestos.

Isso conversa direto com o tema da edição de duas semanas atrás: ter duas regiões não é ter duas chances. A camada que decide para onde o usuário vai quando uma região cai costuma ser a única peça da arquitetura que continua sendo clicada na mão — e a única que ninguém testa até o dia do incidente.

A promoção a incubating não muda o código, muda o critério de adoção. Para comitê de arquitetura que exige maturidade formal antes de aprovar um projeto open source em produção, sandbox era um obstáculo e incubating não é. O projeto está no ecossistema desde março de 2021 e a CNCF cita adoção em serviços financeiros, incluindo o banco português Millennium bcp.

Quer saber se o seu failover entre regiões funciona fora do slide? Podemos testar isso com você.

E a outra metade da semana, que veio com contrato?

Enquanto a comunidade padronizava, os provedores entregavam conveniência — e cada entrega tem um custo de portabilidade embutido.

Movimento	Estágio	O que resolve	O que amarra
Gateway API v1.6 (TCPRoute/UDPRoute)	Standard, `v1`	Roteamento L4 declarativo no cluster	Nada — troca de controller preserva o manifesto
K8gb	Incubado na CNCF	Failover e balanceamento global entre clusters	Nada — opera sobre CoreDNS e external-dns
Oracle Interconnect for AWS	GA	Link privado OCI↔AWS, sem taxa de egress	Par de regiões e contrato dos dois provedores
Azure VNet routing appliance	GA	Roteamento entre VNets em hardware dedicado	Serviço Azure, sem equivalente portátil
Azure Private Link sobre IPv6	Preview	PaaS acessível por endpoint IPv6 privado	5 regiões, 4 serviços, on-prem só via ExpressRoute
ExpressRoute resiliency guard	Preview	Declara intenção single-homed vs multi-homed	Governança dentro do Azure
Azure DNS + Traffic Manager	Preview	Record set apontando direto ao perfil, sem CNAME manual	Plano de DNS do provedor

O Oracle Interconnect for AWS é o mais interessante dos cinco, e não pela tecnologia. Ele cobra pela capacidade de conexão provisionada e não cobra transferência de dados — em multicloud, egress é exatamente a linha que transforma uma arquitetura distribuída defensável em orçamento reprovado. A limitação é geográfica: a GA começou no par OCI Ashburn e AWS US East (N. Virginia), com outros pares previstos. Para o Brasil, é sinal de mercado, não opção de projeto.

O ExpressRoute resiliency guard merece nota por ser o mais barato de adotar e o mais ignorado. Ele adiciona ao gateway uma propriedade que declara se o desenho é single-homed ou multi-homed, e alerta quando a configuração real não corresponde à intenção. Vale lembrar que o SLA de 99,95% do ExpressRoute só existe em configuração redundante: sem essa validação, é perfeitamente possível operar por anos acreditando ter redundância contratada que a topologia não entrega. Colocar isso numa Azure Policy custa uma tarde.

O que mais mereceu atenção

Custo. O OpenCost lançou a versão 1.121.0 com o primeiro rastreamento de custo de inferência em Kubernetes. É a peça que faltava para o FinOps de IA sair do rateio por namespace: enquanto o custo de GPU é atribuído por nó, ninguém consegue responder quanto custa um agente específico. Rastrear por inferência muda a unidade de cobrança do recurso para o consumo — e é a diferença entre "o cluster de IA custa X" e "este time custa X".

Observabilidade. O Grafana 13 chegou ao Azure Managed Grafana, com Git Sync para versionar dashboards e mudanças na autenticação com Prometheus. Vale ler a nota de autenticação antes do upgrade, não depois. Na mesma frente, o Cortex — backend de longo prazo para Prometheus e OpenTelemetry — concluiu auditoria de segurança conduzida pelo OSTIF, o que é um argumento concreto para quem defende observabilidade self-hosted em comitê de risco.

Segurança. A inteligência de ameaças do Google detalhou o UNC6671, grupo de extorsão que combina vishing com acesso a ambientes cloud corporativos, mirando serviços financeiros — o vetor é a pessoa do help desk, não a sua policy de IAM. A CNCF publicou um threat model de Shadow AI em CI/CD, mapeando o caminho do laptop do desenvolvedor até o cluster: é o roteiro que faltava para quem precisa escrever política de uso de IA sem chutar. E o Azure DevOps passou a permitir substituir PAT e tokens de sessão por identidades federadas na service connection — credencial estática de longa duração em pipeline é dívida que vence sozinha, e agora tem caminho de saída documentado.

Kubernetes. Ainda na CNCF, uma análise direta sobre se o DRA substitui o HAMi no compartilhamento de GPU, e o balanço do LitmusChaos em 2026, com seis releases e o caso do Flipkart como evidência de que engenharia de caos virou prática de operação, não experimento de conferência.

O que isso muda para quem opera infra no Brasil?

Três decisões que cabem nesta semana:

Inventarie o seu L4 exposto. Liste todo Service do tipo LoadBalancer e toda anotação de TCP/UDP específica de controller. Cada item dessa lista é um ponto onde a sua rede está presa a uma implementação — e agora existe uma alternativa no canal Standard. Não migre tudo; migre o que já convive com Gateway API no mesmo cluster.
Decida onde mora a regra de failover. Se a resposta para "o que acontece quando a região cai" está num console de provedor, ela não está versionada, não está testada e não sobrevive a uma troca de nuvem. K8gb é a opção portátil que acabou de ganhar selo de maturidade; Traffic Manager e Route 53 são as opções gerenciadas. Escolher é legítimo — não escolher é o problema.
Trate conveniência de rede como decisão de arquitetura. Interconnect, appliance gerenciado e Private Link resolvem problemas reais e economizam meses. Também estabelecem onde o seu tráfego pode ir. Nenhum desses anúncios é armadilha; todos são compromissos. A pergunta a fazer antes de adotar é simples: se eu precisar sair, o que exatamente eu reescrevo?

O padrão desta semana é o que vem se repetindo no cloud native desde a Gateway API: a comunidade padroniza a interface, os provedores competem na implementação. Quem escreve contra o padrão troca de fornecedor sem reescrever. Quem escreve contra o produto ganha meses agora e paga depois — e a fatura raramente chega no momento em que dá para negociá-la.

Perguntas Frequentes

TCPRoute em Standard significa que posso jogar fora meu Service do tipo LoadBalancer?
Não, e essa não é a troca certa de fazer. O que mudou é que TCPRoute e UDPRoute saíram do canal Experimental para o Standard e passaram para a versão v1, com a v1alpha2 marcada para remoção. Você ganha uma forma declarativa e portátil de expor TCP e UDP bruto — banco de dados, DNS, VoIP, MQTT — sem anotação proprietária. O Service do tipo LoadBalancer continua sendo o caminho mais curto para um caso simples. A migração compensa quando você já tem Gateway API no cluster para HTTP e quer o mesmo modelo de recurso e a mesma separação de responsabilidade no L4. Antes de migrar, confirme que o seu controller implementa TCPRoute e UDPRoute no canal Standard: promoção na especificação não é implementação disponível no seu ambiente.

O que é esse novo grupo de API gateway.networking.x-k8s.io?
É a separação formal entre o que é estável e o que ainda é experimento. A partir do v1.6, recursos experimentais vivem no grupo gateway.networking.x-k8s.io, com prefixo X no nome, enquanto gateway.networking.k8s.io fica reservado ao canal Standard. Dá para olhar um manifesto e saber, pelo grupo, se aquele recurso tem garantia de compatibilidade. O primeiro recurso sob a nova convenção é o XBackend, voltado a tráfego de saída. Para time de plataforma, isso vira política de admissão de uma linha: bloquear o grupo x-k8s.io em produção e liberar em teste, algo que antes exigia inspeção recurso a recurso.

O K8gb substitui o Traffic Manager ou o Route 53 para failover entre regiões?
Ele resolve o mesmo problema por outro caminho. O K8gb faz GSLB usando APIs padrão do Kubernetes, CoreDNS e external-dns, em vez de um serviço gerenciado — a lógica de failover fica nos seus manifestos e viaja com eles. O tradeoff é honesto: serviço gerenciado transfere a operação do plano de DNS para o provedor; o K8gb devolve essa responsabilidade ao seu time. A promoção a projeto incubado da CNCF é o sinal que faltava para quem exigia maturidade formal antes de adotar. O projeto está no ecossistema desde o sandbox, em março de 2021, com adoção declarada em serviços financeiros, incluindo o Millennium bcp.

O Oracle Interconnect for AWS já serve para uma empresa brasileira?
Ainda não em produção, por geografia. A GA começou no par OCI Ashburn e AWS US East (N. Virginia), com outros pares previstos para os próximos meses. Enquanto São Paulo não entrar na lista, o desenho para o Brasil continua sendo conectividade própria ou parceiro de trânsito. O que vale acompanhar é o modelo comercial: cobrança pela capacidade provisionada, sem taxa de transferência de dados, com suporte coordenado entre os provedores. Egress entre nuvens é a linha que costuma reprovar arquitetura distribuída no orçamento — se o padrão pegar, a pergunta deixa de ser quanto custa sair e passa a ser quanto custa manter o link.

Faz sentido trocar meu NVA em VM pelo routing appliance do Azure?
Depende do papel que a VM exerce. O routing appliance entrou em GA como serviço gerenciado de roteamento entre VNets, com plano de dados em hardware dedicado — menos latência e throughput mais previsível que roteamento em software, sem patch e escala de VM. O que ele não faz é inspeção: firewall de aplicação, DPI e filtragem seguem com Azure Firewall, NSG ou appliance de segurança. Se a VM só encaminha pacote, a troca tende a compensar em tráfego alto. Se ela inspeciona, o appliance apenas tira o roteamento do caminho. Em qualquer cenário, confirme a disponibilidade em Brazil South antes de desenhar a migração.

Fontes: