Everything new with Istio 1.22

Imran Roshan
Google Cloud - Community
6 min readMay 18, 2024

A detailed overview of new features on Istio 1.22

Bringing a slew of innovative features and enhancements to the service mesh market Istio 1.22 makes a great offering for some enhanced features. Offering improved functionality, operational efficiency, and security for microservice deployments, this release represents a major advancement. We’ll go over everything new with Istio 1.22 in this extensive blog, offering thorough explanations, code samples, and insights to help you make the most of it.

Ambient Mode

The eagerly awaited ambient mode beta release is now available in Istio 1.22. By separating the necessity for sidecar injection from your applications, this ground-breaking method seeks to streamline service mesh operations. This is how it operates:

  • Shared Node Proxies: In a traditional sidecar injection, each application pod receives a separate instance of an Envoy proxy. Lightweight shared node proxies are introduced in ambient mode and are installed on every host. Core service mesh functions like traffic management and security are managed by these proxies.
  • Optional Layer 7 Envoy Per-Workload Proxies: Ambient mode enables the deployment of a specific Layer 7 Envoy proxy in addition to the application container for workloads needing sophisticated functionality like traffic shaping or protocol translation. This method minimizes resource usage while offering a fine-grained control layer.

The advantages of ambient mode are strong.

  • Decreased Memory and CPU Overhead: Experiments have demonstrated that ambient mode, as opposed to sidecar injection, can dramatically reduce memory usage and CPU overhead by over 90%. This means that your clusters will use their resources more effectively and save money.
  • Simplified Operations: Removing sidecar injection makes deployments easier and does away with the requirement to change application code. As a result, service mesh development and operational workflows are streamlined.

For example, in addition to enabling ambient mode with service account annotation propagation, we also enable tracing and permit all outgoing traffic.

meshConfig:
enableTracing: true
outboundTrafficPolicy:
mode: ALLOW_ANY
pilot:
enableMeshExternal: true
ambient:
enabled: true
propagateAnnotations:
istio.io/service-account: true

Recall that ambient mode is still in beta. Even though it has many benefits, it is advised to test it thoroughly in non-production settings before implementing it in workloads that are too important.

Path Templating in AuthorizationPolicy

Path templating is introduced in AuthorizationPolicy resources in Istio 1.22. This much-needed feature improves security granularity by enabling you to create adaptable path matching rules for access control.

In the past, each path you wished to protect with an AuthorizationPolicy had to be listed explicitly. You can now create patterns that match multiple paths by using Envoy’s wildcard functionality with path templating.

Coming to an example YAML file, using the wildcard “{*}” to represent any string, the AuthorizationPolicy in this example prevents access to all GET requests on paths beginning with “/reviews/”. This gives users within the ratings service fine-grained control over read access to specific book reviews.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: bookinfo-read-only
spec:
selector:
app: ratings
rules:
- from:
- source.namespace: user
- to:
- operation:
methods: ["GET"]
path: /reviews/{*} # Path with wildcard for any review ID

By enabling you to create access control policies that are more expressive and succinct, path templating makes security management for intricate microservice architectures easier.

Enhanced Functionality and Usability

Istio 1.22 introduces a number of extra enhancements aimed at improving usability and functionality:

  1. Support for the PROXY protocol for outgoing traffic: Istio can now be set up to send the PROXY protocol headers to services that are upstream using DestinationRule resources. This enhances the ability to see where inbound connections are coming from, which helps with network troubleshooting.
  2. Duplicate Subset Name Validation Checks: Istio 1.22 adds validation checks to stop DestinationRules from being created with duplicate subset names. By doing this, possible configuration errors are avoided and consistency is maintained.
  3. Promoted istioctl command for proxy status: Previously in an experimental stage, the istioctl proxy-status command is now formally promoted. This command gives you information about the state and setup of the Envoy proxies that are used in your service mesh.

APIs promoted to v1

The following core APIs are graduated to v1 in Istio 1.22:

  • DestinationRule: Specifies the rules for traffic routing among services in a mesh.
  • Gateway: Sets up ports of entry into the mesh for outside traffic.
  • ServiceEntry: Enables the mesh to incorporate external services.
  • Sidecar: Specifies how sidecar proxies should be inserted into application pods.
  • VirtualService: Manages the mesh’s traffic routing between services.
  • WorkloadEntry: Allows workloads to be added to the mesh on a chosen basis.
  • WorkloadGroup: Mesh configuration application workloads are grouped together.
  • Telemetry API (Partially): v1alpha1 retains some alpha features even though the core functionality of the Telemetry API is being promoted.
  • Peer authentication: Describes how mesh services mutually authenticate using TLS.

Istio 1.22 retains backward compatibility, which is good news. The v1beta1 versions of these APIs will still work with deployments that are currently in place. But moving to v1 is advised if you want to take advantage of its stability and possible upgrades in the future.

The upgrade procedure is simple. All you have to do is change the “v1beta1” API version in your Istio resource definitions to “v1.” As an illustration, consider this:

# v1beta1 version (previous configuration)
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule

# v1 version (updated configuration)
apiVersion: networking.istio.io/v1
kind: DestinationRule

Gateway API

This is probably the single update I am most excited about, the Kubernetes Gateway API has formally attained stable status for service mesh use cases. This is a big step forward toward a standardized and unified approach to traffic management in service meshes.

Compared to more conventional approaches like Istio’s Virtual Services and Destination Rules, this facilitates consistency and simplifies configuration.

What are the benefits?

  • Unified Traffic Management: Whether it’s east-west or ingress (north-south) traffic within the service mesh, the Gateway API serves as a single source of truth for all traffic routing configurations. This makes things more manageable and less complicated.
  • Declarative Approach: Using Gateway resources, you specify the desired routing behavior, and Istio converts these configurations into the relevant underlying mechanisms (like Envoy filters) for enforcement. This lowers the possibility of errors and simplifies configuration.
  • Vendor Neutrality: The Gateway API is not Istio-specific; rather, it is a standard API. As a result, it can be utilized by other service meshes as well, fostering interoperability and future-proofing your configurations.

This is a sample of YAML code that shows how to expose a service called “reviews” on port 9080 using a basic Gateway resource. Here, we define a Gateway called “reviews-gateway” that is set to listen for HTTP traffic on port 80. This traffic is routed by the Gateway to the port 9080 “reviews” service.

apiVersion: networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: reviews-gateway
spec:
servers:
- port:
number: 80
name: http
routes:
- destinations:
- port:
number: 9080
to:
kind: Service
name: reviews

Delta xDS

Istio used a “state of the world” (SotW) method for configuration distribution before implementing Delta xDS. With this approach, the control plane would broadcast the complete configuration state to all Envoy sidecars whenever a change occurred in the service mesh (e.g., a new service deployed, an update to a traffic policy).

Delta Extension for Discovery Service, or Delta xDS, introduces an incremental update mechanism to address these problems. This is how it operates:

  • First Snapshot: In order to give the sidecars access to the initial state of the service mesh, Istio sends a full configuration snapshot to them during deployment.
  • Updates After: Upon modification, the control plane only sends the precise deltas (differences) between the modified and original configuration. This drastically lowers the quantity of data that is transferred.
  • Updates for Sidecars: Sidecars get these deltas and quickly incorporate them into their current setup to make sure they always have the most recent version of the service mesh displayed.

This in turn can reduce network traffic and resource consumption.

Conclude

Istio 1.22 provides strong reasons to update, regardless of your experience level with Istio or whether you’re just getting started with service meshing. Utilize these fresh features to maximize Istio’s capabilities and achieve new levels of success with your microservice deployments.

Note: Although this blog post offered a broad overview, for comprehensive setup options and recommended practices for implementing Istio 1.22 in your environment, consult the official Istio documentation. Cheers to meshing!

Connect!

--

--

Imran Roshan
Google Cloud - Community

Your security sherpa | Google Developer Expert (GCP) | Ethical Hacker | Cloud Security