Istio 1.18 separates the mesh data plane from application pods

A sidecar avoids changing application code, but it still couples the proxy's deployment to the application pod. Installing or upgrading that proxy changes the pod carrying the application. A workload that only needs mesh transport security also receives a proxy capable of much more expensive application-protocol processing. Ambient mode separates those requirements into different components.

Istio 1.18, released on June 7, is the first Istio release to contain ambient mode. The announcement labels it alpha and explicitly says it is not recommended for production. Its significance is the availability of a different deployment model to evaluate, with transport functions separated from optional Layer 7 processing.

I regard workload identity as a strong reason to consider Istio, while its operating cost remains substantial. A deployment model that lets identity and encrypted transport exist without a full proxy in every application pod addresses that tradeoff directly. It still needs to be judged as an alpha system with its own operational dependencies.

A node tunnel handles the secure overlay

The ambient architecture introduction describes a shared agent called ztunnel on each node. Traffic from participating workloads is redirected through that local component. Ztunnel handles secure connections and authentication without performing Layer 7 parsing on workload traffic.

The division is deliberate. Encrypting and authenticating a connection does not necessarily require parsing its HTTP requests. Keeping those functions in a limited shared component allows the baseline transport layer to serve workloads that do not need application-protocol traffic management. An operator can then add a separate component when Layer 7 policy is required.

This changes where deployment coupling occurs. A sidecar lives in the pod whose traffic it handles. A node-level transport component lives in the infrastructure serving several workloads. Its upgrades and resource allocation are no longer expressed as another container in every application pod, although the shared component becomes an infrastructure dependency those workloads rely on.

That is a tradeoff in failure scope as well as an opportunity for different resource management. Sharing a component means its operational state matters to more than one workload. The architecture needs a narrow responsibility and a clear security model for that shared role. The introduction identifies limiting ztunnel to transport-level processing as part of the design.

Waypoints add application-protocol policy where needed

Envoy-based waypoints handle Layer 7 processing outside application pods. The March waypoint explanation describes namespace-scoped or service-account-scoped proxies and moves policy enforcement toward the destination. They can be deployed and scaled separately from the applications whose incoming traffic they process.

The resulting model distinguishes participating in the secure overlay from requesting HTTP-aware processing. A namespace can use the former without automatically requiring the latter. This gives the operator a more specific adoption unit than inserting a full-featured sidecar everywhere simply to obtain encrypted, authenticated transport.

Destination-oriented processing also changes configuration distribution. A waypoint needs configuration for its own managed scope. The March article contrasts that with source sidecars learning destination information across the mesh. That design can reduce unnecessary configuration delivery, while the actual result depends on deployment shape and existing scoping in a sidecar installation.

The authors use HBONE, HTTP CONNECT over mTLS, for the tunnels between ambient components. That gives the transport layer a way to insert waypoint processing into the path. The protocol is part of how the separated components cooperate, rather than requiring the application to become aware of their deployment locations.

The release supplies an alpha, not a universal replacement

The 1.18 announcement makes ambient's maturity limit explicit. Shipping in a release makes it easier to evaluate through the project's distribution, but it does not establish the operating commitment attached to stable functionality. Describing the release as sidecar-free production Istio would erase a qualification the maintainers state directly.

The architecture also leaves a role for existing sidecars. The original introduction discusses interoperability and choosing capabilities according to workload requirements. Its central proposition is another data-plane option. It does not require an operator to infer that every existing workload should move immediately or that the deployment tradeoffs have disappeared.

I find the ability to choose the Layer 7 deployment separately particularly relevant. Istio's value is uneven across workloads. A fleet may need a common identity basis while only some destinations need HTTP-aware routing and authorisation. A layered model can express that difference without assigning every application the same proxy arrangement.

The release's other changes remain relevant to users who retain sidecars. Ambient is the major architectural addition, but the upgrade also changes how existing gateway infrastructure is generated and how proxy worker concurrency is selected. Those changes have their own migration rules independent of adopting the alpha.

Managed gateways stop depending on pod injection

The 1.18 upgrade notes describe a change to Kubernetes Gateway API automated deployment. Previously, Istio created a minimal Deployment and relied on injection to populate the pod at runtime. Restarting pods triggered re-injection for an upgrade.

In 1.18, Istio creates a fully rendered Deployment instead. A revision change updates the Gateway through a rolling restart. This moves the generated configuration into the Deployment itself and changes the lifecycle event that causes the proxy to update. The maintained object becomes a more complete description of what the controller intends to run.

The scope is specific to Kubernetes Gateway API automated deployment. It does not describe every resource named Gateway, particularly Istio's separate Gateway API. Distinguishing the API groups matters because similar resource names do not imply identical deployment management.

Users of the automated deployment feature must first update their control plane to 1.16.5 or newer in that line, or 1.17.3 or newer in that line. The notes warn that skipping this prerequisite can produce conflicting writes to the same resources. That makes the source-side patch part of the upgrade protocol, rather than an optional refinement after the target control plane is installed.

Proxy concurrency follows the container's CPU limit

The upgrade notes also resolve inconsistent worker concurrency across deployment types. Previously, gateways could choose concurrency from physical host cores despite a container CPU limit. Sidecars followed CPU-based logic but could determine the limit incorrectly. The result depended partly on how the proxy had been installed.

The new rule uses ProxyConfig.Concurrency when explicitly configured. Otherwise it determines concurrency from the CPU limit allocated to the container. The notes give 2500m as an example producing three worker threads. That is a configuration rule tied to the container allocation, not a measurement of useful parallelism for every traffic mix.

The notes explain how to retain the old all-core gateway behaviour with an explicit concurrency setting of zero, while recommending removal of CPU limits if that behaviour is desired. Their main correction is consistency. Sidecars and gateways should no longer acquire different concurrency semantics merely because different installation mechanisms supplied them.

For an operator, CPU limits now have an explicitly documented relationship to the default thread count. A resource change can therefore affect more than scheduling or throttling. It can also change the proxy's chosen worker concurrency when no override is present. That relationship belongs in the explanation of the deployed configuration.

Compatibility still has concrete version boundaries

Istio 1.18 is officially supported on Kubernetes 1.24 through 1.27. Its change notes also require Gateway API users to have version 0.6.0 or newer before upgrading. They move several resource reads to v1beta1 and say istioctl x precheck can detect the incompatible state.

These boundaries make the architectural release operationally specific. Evaluating ambient, updating managed gateways, and retaining ordinary sidecars are different choices within the same release. Each uses a declared deployment model and a documented compatibility range. The alpha provides a new way to separate transport from Layer 7 processing, while the upgrade rules define how existing installations reach that release without relying on conflicting resource writers or implicit proxy defaults.

The change notes also add a revision annotation to sidecars and gateways for observability across revisions. That gives the migration state a concrete place in the generated workload metadata. In a system deliberately supporting several control planes during an upgrade, being able to identify the revision associated with a proxy is useful evidence about which configuration path is under examination.