The recent release of Istio 1.22 includes a plethora of significant updates. This article shares the new features and application recommendations brought by this release.

Ambient Mode Enters Beta Phase

Although Ambient mode has now entered the Beta phase, this does not mean we can completely do away with Sidecars. While the Istio official claims that Ambient mode simplifies operations and significantly reduces memory and CPU usage, it still has limitations and potential complexity issues. For example, while Sidecars are eliminated, the introduction of new ztunnel and waypoint components may pose new challenges. For more detailed information about Ambient mode entering Beta, refer to the Istio official blog.

Challenges Introduced by Ambient Mode

• Management of L7 traffic in Ambient mode is not yet mature
• mTLS is forced to be enabled at the namespace level, meaning you cannot disable mTLS in Ambient mode
• Zero-downtime upgrades in Ambient mode have not been resolved
• Lack of best practices for coexistence and migration from Sidecar mode

For a comparison of Sidecar mode and Ambient mode, see Analysis of Limitations in Istio Ambient Mode.

Istio API Upgrades

In the Istio 1.22 release, key APIs related to traffic management, security, and telemetry have officially been upgraded to the v1 version. You only need to change the API version of your existing configuration to v1, with no other changes needed. These APIs are already mature, and you can safely use the v1 version. For environments requiring high stability, Istio has added validating admission policies to ensure that only v1 APIs and fields can be used in the Istio API.

For example, the following AuthorizationPolicy example.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: finance-to-supply-chain
  namespace: finance
spec:
  selector:
    matchLabels:
      app: finance-app
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["finance"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/supply1", "/api/supply2"]
    when:
    - key: request.headers[:authority]
      values: ["supply-chain-service.supply-chain.svc.cluster.local"]

Other extension-type APIs such as EnvoyFilter, WasmPlugin, ProxyConfig are still in alpha or beta stages. For more information on API upgrades, please refer to the v1 API blog.

Gateway API Upgrade

Gateway API has been updated to version 1.1.0 and is now widely available. This update extends Istio’s traffic management capabilities, but it is important to be cautious of compatibility issues between Istio’s native APIs and the Gateway API when migrating to the new API to avoid relying on features that are not fully mature yet. For more details, check out the Gateway API v1.1 blog.

Delta xDS Enabled by Default

Istio 1.22 version now has delta xDS enabled by default, which is a mechanism to optimize configuration distribution. Compared to the traditional State of the World (SotW) mode, delta xDS only sends changed configurations to the Envoy proxies, thereby significantly reducing the amount of data transmitted over the network and the resource consumption of the control plane. This change is particularly suitable for large-scale deployment environments with frequent configuration updates, improving the efficiency and performance of configuration updates. Additionally, delta xDS also helps manage configuration updates more efficiently in complex network environments or dynamically changing configurations.

For more on xDS, refer to the Introduction to Envoy xDS and Configuration Distribution Process in Istio.

Path Template Support with Wildcards for AuthorizationPolicy

In Istio 1.22, AuthorizationPolicy has added support for path templates, greatly enhancing the flexibility and precision of path matching. Prior to this, AuthorizationPolicy did not support wildcards in path configurations. This feature allows for defining paths in HTTP requests using URI templates based on Envoy, including simple wildcards (* and **) or named variables, enabling precise matching of single or multiple path components. For example, the path template /foo/{*} can match /foo/bar but not /foo/bar/baz, while /foo/{**}/ can match any path starting with /foo/. This flexible path template design is particularly suitable for dynamic and complex routing rules, further strengthening Istio’s security policy toolbox.

The diagram below illustrates the wildcard rules for path matching in AuthorizationPolicy.

For more on the specific applications and rules of path templates, you can refer to Envoy’s official documentation.

Summary

The Istio 1.22 release introduces several important updates and improvements. Although some features are widely publicized, they require detailed assessment and appropriate testing in practical use. Hopefully, this blog post helps you understand and apply these new features more deeply to achieve the best results in practice.

References

• Gateway API v1.1: Service mesh, GRPCRoute, and a whole lot more - kubernetes.io

This blog was initially published at tetrate.io.