BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Istio 1.31 Adds Agentgateway Waypoints and Moves Release Artifacts off Google Cloud

Istio 1.31 Adds Agentgateway Waypoints and Moves Release Artifacts off Google Cloud

Listen to this article -  0:00

Istio 1.31, released on 31 August, lets teams run agentgateway as a Layer 7 waypoint proxy in an ambient mesh, using the new istio-agentgateway-waypoint GatewayClass.

The same release stops publishing container images and Helm charts to Google Cloud. Teams still using gcr.io/istio-release, registry.istio.io, or the Google-hosted Helm repository should migrate before the next scheduled outage test on 13 October, ahead of their retirement in December. Istio 1.31.0 is supported on Kubernetes 1.32 to 1.36.

The waypoint support builds on the experimental gateway-only integration added in 1.30. Agentgateway is a Rust data plane built for agent traffic, donated by Solo.io to the Linux Foundation, and it handles protocols such as the Model Context Protocol alongside ordinary HTTP. Istio 1.31 also fixes ListenerSet handling and mTLS connectivity for agentgateway backends. Traffic shifting between waypoints is alpha, and the maintainers warn that the labels, annotations, and behaviour may change.

That shifting mechanism is new too. A service or namespace can name a canary alongside its primary waypoint through the use-waypoint-canary label, then send a configurable share of new in-mesh connections to the canary using the use-waypoint-canary-weight annotation, with no client-side changes. Established connections are not moved, so long-lived connections can delay the observed traffic split.

Istio 1.31.1, released on 21 September, fixes an issue where agentgateway waypoints referenced only as canaries were not programmed with the routes and policies of the services referencing them, causing shifted connections to be rejected. The patch also includes security fixes and corrects ALLOW_ANY_DYNAMIC_DNS forwarding in IPv6-only clusters.

Two traffic management additions stand out for large meshes. A new zoneAwareLbSetting field on DestinationRule and MeshConfig lets Envoy route to endpoints in the downstream proxy's own availability zone and spill over only when local capacity runs out, which Envoy decides automatically rather than through the static percentages localityLbSetting requires. The ALLOW_ANY_DYNAMIC_DNS outbound mode resolves hostnames from the HTTP Host header at request time, removing the need to write a ServiceEntry for every external destination.

On security, a fips-140-3 value for the COMPLIANCE_POLICY environment variable restricts TLS to version 1.2 or later, FIPS-compliant cypher suites and P-256 and P-384 curves. The change notes specify that Go components must be built with Go 1.24 or later using GOFIPS140=v1.0.0 or a later validated version; setting the runtime policy alone is insufficient. New trustDomains and notTrustDomains fields on AuthorizationPolicy match or exclude requests by the trust domain taken from the peer certificate.

The hosting change requires action from teams using the existing repositories. Writing on the Istio blog on 21 August, Steven Jin of Microsoft and Keith Mattix of Solo.io said "this year, Istio is migrating all of our infrastructure from Google Cloud Platform to Amazon Web Services due to changes in our funding model". The next scheduled scream test will disable the old endpoints on 13 October from 15:00 to 18:00 UTC; the final test runs from 8 December at 15:00 UTC to 9 December at 15:00 UTC. Teams verifying image signatures also need to account for key rotation: the migration guidance lists istio-key.pub for 1.31.0 and istio-key-v2.pub for 1.31.1 onwards. Asked on the tracking GitHub issue why the project chose Docker Hub over GHCR, Jin replied that "GHCR has some undocumented limits" and added, "I think we would easily blow past those given our current usage".

About the Author

Rate this Article

Adoption
Style

BT