Publicado em 03 de outubro de 2026· 4 min de leitura

    Istio 1.31 adiciona waypoints com agentgateway e retira artefatos do Google Cloud

    Capa do post sobre o Istio 1.31, agentgateway e migração de artefatos, com o título em branco sobre fundo navy e uma malha de nós conectados em tons de dourado

    O Istio 1.31, lançado em 31 de agosto, passa a aceitar o agentgateway como proxy waypoint de camada 7 no ambient mesh. A versão também encerra a publicação de imagens de contêiner e charts Helm no Google Cloud, exigindo migração antes da retirada dos repositórios antigos em dezembro.

    Segundo a cobertura do InfoQ, o Istio 1.31.0 oferece suporte a Kubernetes de 1.32 a 1.36. As mudanças combinam uma nova opção de data plane para tráfego de agentes, recursos de roteamento para meshes grandes e uma alteração operacional na distribuição dos artefatos do projeto.

    Agentgateway entra no ambient mesh

    Equipes podem usar o agentgateway como waypoint por meio da GatewayClass istio-agentgateway-waypoint. O projeto é um data plane escrito em Rust, doado pela Solo.io à Linux Foundation, projetado para tráfego de agentes e protocolos como Model Context Protocol, além de HTTP convencional.

    O suporte amplia a integração experimental limitada a gateways introduzida no Istio 1.30. A versão 1.31 também corrige o tratamento de ListenerSet e problemas de conectividade mTLS com backends atendidos pelo agentgateway.

    Na prática, a mudança permite experimentar o agentgateway dentro do modelo de ambient mesh, em vez de mantê-lo apenas como gateway isolado. Rotas e políticas associadas aos serviços precisam ser programadas corretamente no waypoint, ponto que recebeu uma correção específica no Istio 1.31.1.

    Canary divide novas conexões

    O novo mecanismo de transição permite que um serviço ou namespace indique um waypoint canário ao lado do principal. A seleção usa o label use-waypoint-canary, enquanto a annotation use-waypoint-canary-weight define a parcela direcionada ao canário.

    A divisão ocorre sem mudanças nos clientes, mas vale somente para novas conexões dentro do mesh. Conexões já estabelecidas não são movidas. Como consequência, workloads com conexões de longa duração podem demorar para refletir a proporção configurada.

    O Istio 1.31.1, lançado em 21 de setembro, corrigiu uma falha relevante nesse fluxo. Waypoints referenciados apenas como canários não recebiam as rotas e políticas dos serviços que os apontavam, fazendo com que as conexões desviadas fossem rejeitadas. O patch também trouxe correções de segurança e ajustou o encaminhamento ALLOW_ANY_DYNAMIC_DNS em clusters exclusivamente IPv6.

    Roteamento e segurança ganham opções

    Para meshes grandes, o campo zoneAwareLbSetting em DestinationRule e MeshConfig permite ao Envoy priorizar endpoints na mesma zona de disponibilidade do proxy downstream. O tráfego excedente é enviado a outras zonas quando a capacidade local se esgota, com decisão automática do Envoy, em vez dos percentuais estáticos exigidos por localityLbSetting.

    Já o modo outbound ALLOW_ANY_DYNAMIC_DNS resolve o hostname presente no cabeçalho HTTP Host durante a requisição. Isso elimina a necessidade de criar um ServiceEntry para cada destino externo.

    Na área de segurança, o valor fips-140-3 para COMPLIANCE_POLICY restringe TLS à versão 1.2 ou posterior, suítes compatíveis com FIPS e curvas P-256 e P-384. A configuração em runtime não basta: componentes Go precisam ser compilados com Go 1.24 ou posterior e GOFIPS140=v1.0.0, ou uma versão validada mais recente. AuthorizationPolicy também ganhou trustDomains e notTrustDomains para incluir ou excluir requisições pelo domínio de confiança extraído do certificado do peer.

    Repositórios antigos serão desligados

    Imagens e charts deixam de ser publicados nos endpoints hospedados pelo Google. Equipes que ainda usam gcr.io/istio-release, registry.istio.io ou o repositório Helm antigo devem migrar antes da retirada definitiva em dezembro.

    O próximo teste de indisponibilidade está programado para 13 de outubro, das 15h às 18h UTC. O teste final ocorrerá de 8 de dezembro, às 15h UTC, até 9 de dezembro no mesmo horário. De acordo com o relato reunido pelo InfoQ, a infraestrutura está migrando do Google Cloud para a AWS devido a mudanças no modelo de financiamento.

    A migração também envolve rotação de chaves para quem valida assinaturas: istio-key.pub corresponde à versão 1.31.0, enquanto istio-key-v2.pub vale para a 1.31.1 em diante. O projeto escolheu Docker Hub em vez de GHCR citando limites não documentados que poderiam ser superados pelo uso atual.

    Ressalvas e adoção

    O balanceamento de tráfego entre waypoints ainda está em estágio alfa. Labels, annotations e comportamento podem mudar, e conexões persistentes tornam a divisão observada diferente da configuração imediata.

    O agentgateway faz sentido para equipes que já operam ambient mesh e precisam tratar tráfego HTTP ou MCP em waypoints, desde que aceitem a instabilidade da funcionalidade canário. Não é uma escolha adequada como mecanismo estável de rollout enquanto o recurso permanecer alfa. Independentemente da adoção do novo data plane, a migração dos repositórios é necessária para evitar falhas na obtenção de imagens e charts após a desativação dos endpoints antigos.

    Compartilhar:

    Leia também

    Fontes

    Maxwell Diniz
    Maxwell Diniz

    Fundador da DEVDINIZ

    Software em produção

    51 ferramentas gratuitas, direto no navegador

    Utilitários para CPF, CNPJ, JWT, JSON, regex, cores e mais. Processamento local, sem cadastro e sem conta — a mesma engenharia que sustenta o que escrevemos aqui.