Istio 1.32.0 chega com suporte a Kubernetes 1.33 a 1.37
Aprofundamento CEVIU
Aprofundamento
O Istio 1.32.0 foi publicado com suporte declarado ao Kubernetes 1.33 a 1.37. A release trouxe uma lista grande de mudanças voltadas a operação. A mais visível é experimental: AuthorizationPolicy agora pode apontar para um HTTPRoute da Gateway API via targetRefs, e as regras ALLOW e DENY valem só para o tráfego daquela rota. Também entra o suporte experimental a XBackend, que descreve como clientes devem se conectar a destinos específicos.
Em malhas mistas, um gateway istio-east-west pode atender o tráfego multi-network de sidecars por um listener AUTO_PASSTHROUGH na porta 15443. Com isso, não é mais preciso um gateway east-west separado para sidecars em cada cluster. Exige AMBIENT_ENABLE_MULTI_NETWORK. No balanceamento, a política backendUtilization no DestinationRule usa relatórios de carga ORCA para mandar menos requisições a endpoints ocupados. O outlier detection ganhou outlierDetectionHttpErrorCodes e failurePercentageThreshold, e o campo defaultInboundHttpRetryPolicy configura (ou desliga, com {}) o retry padrão de entrada nos sidecars.
Há ajustes de segurança e observabilidade: jwtRules podem ser marcadas como REQUIRED, PILOT_DISABLE_SELF_SIGNED_CA impede o istiod de gerar ou reaproveitar uma raiz autoassinada, e o pilot-agent repassa histogramas nativos do Prometheus quando o scraper pede. Os gateways com TLS aceitam alpnProtocols e ecdhCurves. O analyzer IST0178 avisa quando um EnvoyFilter insere filtro HTTP junto de uma AuthorizationPolicy ligada a HTTPRoute. Os charts não definem mais GOMAXPROCS.
O que mudou
A cobertura anterior ajuda a situar o contexto. Em 5 de agosto de 2026, o CEVIU noticiou "Gateway API v1.6 Eleva Roteamento TCP/UDP a Padrão e Inova com XBackend". O XBackend, que lá aparecia como novidade da Gateway API, agora ganha suporte experimental no Istio 1.32. Já em 11 de setembro de 2026, o CEVIU publicou "Kubernetes v1.37 Aprimora Gerenciamento de Nodes com Novas Condições de Ciclo de Vida", e o Kubernetes 1.37 agora está na faixa de versões suportadas pelo Istio.
Por que isso importa
Para quem opera malha em produção, a faixa 1.33 a 1.37 dá folga para atualizar o Kubernetes sem perder suporte do Istio. Quem usa Gateway API pode testar autorização por rota em ambiente de staging, lembrando que o recurso é experimental. Para quem mantém ambiente ambient e sidecar juntos, a consolidação do east-west tende a reduzir gateways e custo. Vale ler as notas de upgrade antes de subir.
Linha do tempo
Gateway API v1.6 é noticiada, com TCPRoute e UDPRoute como padrão e XBackend.
Kubernetes v1.37 é noticiado, com novas condições de ciclo de vida de Node.
Istio 1.32.0 chega com suporte ao Kubernetes 1.33 a 1.37 e AuthorizationPolicy experimental em HTTPRoute.
Perguntas frequentes
Quais versões do Kubernetes o Istio 1.32 suporta?
O Istio 1.32.0 oferece suporte às versões 1.33 a 1.37 do Kubernetes. Quem está fora dessa faixa precisa atualizar o cluster antes ou junto com a malha.
A AuthorizationPolicy em HTTPRoute já é estável?
Não, é um recurso experimental no 1.32. Ela usa targetRefs para apontar para um HTTPRoute, e as regras ALLOW e DENY valem só para o tráfego daquela rota. Convém validar em ambiente de testes antes de usar em produção.
Preciso de um gateway east-west separado para sidecars?
Em malhas mistas, não mais. Um gateway istio-east-west pode atender o tráfego multi-network dos sidecars por um listener AUTO_PASSTHROUGH na porta 15443. Isso exige AMBIENT_ENABLE_MULTI_NETWORK.
O que muda no balanceamento de carga e nos retries?
A política backendUtilization no DestinationRule usa relatórios de carga ORCA para enviar menos requisições a endpoints mais ocupados. O campo defaultInboundHttpRetryPolicy permite configurar ou desligar o retry padrão de entrada nos sidecars.
Fontes
- istio.iofonte original
- Categoria
- CEVIU DevOps
- Publicado
- 13 de novembro de 2026
- Editoria
- CEVIU DevOps

