Deep Dive into Istio 1.22: New Features and Practical Application Advice

This is an original article by Jimmy Song. You may repost it, but please credit this source: https://jimmysong.io/en/blog/what-is-new-in-istio-1-22/

Click to show the outline

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.

Recommendation

If you are just starting with Istio, especially if you only need to automatically enable mTLS for services, you can consider using Ambient mode at this stage. However, for L7 functionalities, it is recommended to wait until Ambient mode is fully mature before considering it for production use.

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.

Recommendation

For commonly used functionalities, you can confidently use the v1 API. For extension-type APIs that are not yet stable, enabling validating admission policies is recommended to ensure system stability.

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.

Recommendation

For existing deployments that are already stable using Istio API, continue using them, especially in scenarios requiring advanced features. For new deployments, consider using the stable version of the Gateway API to take advantage of its modern traffic management capabilities. Due to existing compatibility issues, do not rashly migrate to the Gateway API, as it may not be worth the risk.

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.

Recommendation

The delta xDS has been developed several versions ago but was not enabled by default. Now that this feature is stable, you can use it with confidence.

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.

AuthorizationPolicy Path Matching Wildcard Rules

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

Tip

AuthorizationPolicy finally supports templates in path matching, so you no longer need to manually add paths one by one in your configurations.

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.