Istio 1.18 is released: officially announces Ambient mode¶

Author: hanxiaop

Pacific Time, June 5^th, 2023 - Istio has officially released version 1.18.

This release marks the second release of Istio in 2023 and the first version to support Ambient mode.

This version update introduces many new features and changes, including but not limited to Ambient mode for Istio, enhanced Kubernetes Gateway API, health check support for non-automatically registered virtual machines, added support for metrics expiration, and improved istioctl analyze .

In this version update, DaoCloud, as a major provider in the Istio community, has contributed to the installation features and optimization, enhancements of istioctl , and adaptation and documentation improvement for Ambient mode. Additionally, DaoCloud's Han Xiaopeng, as the Release Manager for version 1.18, has been involved in the publishing work.

Next, we will discuss some important features and changes in detail.

Ambient Mesh¶

Before introducing Ambient mode, we need to understand the Sidecar mode currently used by Istio and the challenges it faces.

In Sidecar mode, which is the data plane mode currently used by Istio, each application Pod is equipped with a Sidecar proxy (usually Envoy). This proxy is responsible for handling all network traffic in and out of the Pod, thereby providing Istio's core features such as zero-trust security, telemetry, and traffic management.

However, Sidecar mode also has some challenges, including but not limited to:

• Strong intrusiveness: In Sidecar mode, every application Pod needs to inject an Envoy proxy. This means that some applications must consider interactions with the Sidecar proxy during design and coding. Additionally, the upgrade process of the Sidecar may affect the application when upgrading the mesh, making it difficult to decouple mesh capabilities from business containers and increasing the complexity of application development and operations.

• High resource consumption: In Sidecar mode, since each Pod is equipped with an Envoy proxy, this means that additional CPU and memory resources must be allocated for its Sidecar. This not only may waste resources but also increases infrastructure costs.

• Cumbersome security configuration: Although the Sidecar proxy provides secure core functionality, the current configuration is relatively cumbersome. For example, in mTLS, in Sidecar mode, each Pod or different hierarchical workloads need to be configured individually for security features, and operators may need extra time and technology to handle these cumbersome configurations.

It is precisely because of these challenges that Istio has introduced a new data plane mode - Ambient Mesh. This mode aims to simplify operation, expand application compatibility, and reduce infrastructure costs while continuing to provide Istio's core features. For more information, refer to Introducing Ambient Mesh.

Ambient mode has the following benefits:

• Non-intrusive: Compared with the traditional Istio architecture that requires injecting a Sidecar proxy in the application Pod, Ambient Mesh does not require intruding into the application. Only the corresponding label needs to be added, and the application can automatically join the mesh, reducing the impact of the mesh on the application.

• Higher resource utilization: In Sidecar mode, each Pod needs to allocate CPU and memory for the worst-case scenario, which has always been a problem. Ambient Mesh effectively reduces resource waste by sharing the proxy Ztunnel. If some Layer 7 features of Istio are needed, they can also be solved by deploying a Waypoint precisely for a Service Account or Namespace to better control resource consumption.

• Performance: In the early days, Istio adopted a shared proxy model based on Envoy. However, during development, it was found that Envoy had problems such as cumbersome configuration, so Istio developed its own shared proxy (ztunnel) based on Rust. In the future, it is expected that Ambient Mesh will have comparable performance to the traditional Sidecar mode.

• Security: Ambient Mesh ensures security by running a shared proxy Ztunnel on each node. This proxy is deployed on each node and is responsible for handling all traffic in and out of the node. It can provide the same security as the Sidecar proxy in the traditional Istio mesh. Once Ambient mode is enabled for a namespace, a security overlay is created. This overlay provides applications with mTLS, telemetry, identity verification, and L4 authorization features without terminating or parsing HTTP traffic.

However, if L4 cannot meet the requirements of the application, Waypoint can appear as a proxy for L7. Unlike Ztunnel, Waypoint still uses Envoy for traffic proxy and forwarding. An Ambient mode-enabled namespace can handle L7 traffic in the namespace by deploying one or more Waypoints. Unlike the previous Sidecar mode, Waypoint is essentially deployed as a single Envoy like an application Pod, and it can be automatically scaled like other Kubernetes resources.

Users can perform Waypoint configuration management through the command-line tool istioctl x waypoint . For example, by running the istioctl x waypoint generate command, users can generate a Kubernetes Gateway API resource managed by Istio. When this resource is deployed in Kubernetes, relevant resources such as Service, Deployment, and Service Account will be created automatically. Additionally, any modifications to the Gateway will be directly updated on these resources.

Overall, the introduction of Ambient Mesh provides more flexibility for users while reducing the complexity of using the mesh.

Note that Ambient Mesh is currently still in the Alpha stage and has not yet reached production-level stability. We look forward to seeing more updates and improvements in future Istio versions.

Improvements and Changes to Kubernetes Gateway API¶

Istio 1.18 introduces several significant improvements and modifications to the Kubernetes Gateway API:

1. Support for version v1beta1: When upgrading to the new version of Istio, note that the required version of the Gateway API must be greater than 0.6.0+. You can use the istioctl x precheck command to check for upgrade issues.

2. Management upgrade for Gateway API automated deployment: Any K8S Gateway resource managed by Istio will automatically configure Service and Deployment resources when created or updated. If the Gateway resource changes, related configurations will also be synchronized. Additionally, the deployment of Gateway resources no longer depends on injection logic but has an independent creation process.

3. Removal of support for the proxy.istio.io/config annotation: At the same time, ProxyConfig resources only take effect on Gateways managed by Istio.

4. Fix for Istiod's handling of configuration changes: If Service and Deployment configurations change, Istiod will now reprocess them.

5. Alpha version of the Gateway API is no longer supported by default: It can be re-enabled by setting PILOT_ENABLE_ALPHA_GATEWAY_API=true .

It is worth noting that unlike previous Istio installations, installing Ambient mode does not include IngressGateway by default. In future development, Istio is more inclined to use the Gateway API to manage gateways.

Changes to Concurrency Settings¶

Previously, the concurrency setting was inconsistent between different installation mechanisms for sidecars and gateways. In Istio 1.18, this setting has been adjusted to maintain consistency across different deployment types.

Improvements to Istioctl¶

1. For Ambient Mesh mode, the istioctl x waypoint command has been added to manage Waypoint configurations.

2. istioctl analyze now includes analysis of gateway certificate configuration anomalies and telemetry resource anomalies.

Removed Features¶

1. Support for Ingress version networking.k8s.io/v1beta1 has been removed, and version v1 has been supported since Kubernetes 1.19.

2. The taint controller feature of the experimental Istio CNI has been removed.

3. Support for EndpointSlice version discovery.k8s.io/v1beta1 has been removed, and version v1 has been supported since Kubernetes 1.21.

Upgrade Considerations¶

Proxy Concurrency Changes¶

Previously, the concurrency setting that configures the number of worker threads running the proxy was set inconsistently between sidecars and different gateway installation mechanisms. This often resulted in the gateway running concurrency based on the number of physical cores of the host machine, even with CPU limits, resulting in reduced performance and increased resource usage.

In this release, concurrency configuration has been adjusted to be consistent across deployment types. The new logic will use the ProxyConfig.Concurrency setting (which can be configured across the entire mesh or per pod) and will set concurrency based on the CPU limit assigned to the container if not set. For example, a limit of 2500m will set concurrency to 3.

Before this release, sidecars followed this logic, but sometimes incorrectly determined CPU limits. Gateways will never auto-adapt based on concurrency settings.

To preserve old behavior where gateways always utilize all cores, proxy.istio.io/config: concurrency: 0 can be set on each gateway. However, it is recommended to remove CPU limits if this is the expected behavior.

Changes to Gateway API Automated Deployment¶

This change only affects you if you are using Gateway API automated deployment. Note that this applies only to the Kubernetes Gateway API, not the Istio Gateway . You can use the following command to check if you are using this feature:

kubectl get gateways.gateway.networking.k8s.io -ojson | jq -r '.items[] | select(.spec.gatewayClassName == "istio") | select((.spec.addresses | length) == 0) | "Found managed gateway: " + .metadata.namespace + "/" + .metadata.name' 
Found managed gateway: default/gateway

If you see "Found managed gateway", you may be affected by this change.

Before Istio 1.18, a managed gateway worked by creating a minimal Deployment configuration that was fully populated at runtime through pod injection. To upgrade the gateway, users would restart pods to trigger re-injection.

In Istio 1.18, this has changed and now works by creating a deployment that is fully rendered by Helm and no longer depends on injection. Therefore, when their versions change, gateways will be updated through rolling restarts.

In addition, users using this feature must upgrade their control plane to Istio 1.16.5+ or 1.17.3+ before adopting Istio 1.18. Failure to do so may result in conflicting writes to the same resource.

For all the specific changes, please refer to the release notes for Istio 1.18 here.

Comments