Goodbye Istio Sidecars

Service meshes are a common component in Kubernetes platforms, but their operational cost is a frequent source of friction. Traditional Istio injects an Envoy sidecar into every pod. That design provides deep observability, strong security, and advanced traffic management, but it also adds complexity and resource overhead.

Istio Ambient Mode offers a different model. Instead of placing a proxy next to every workload, Ambient Mode uses shared node level and service level proxies. This reduces cost, simplifies upgrades, and lets teams adopt mesh features incrementally. This article explains how Ambient Mode works, how it differs from traditional Istio, recent developments that make it relevant now, practical examples, operational cautions, and the benefits platform teams can expect.

How Ambient Mode Differs from Traditional Istio

Traditional Istio uses a sidecar per pod. Each Envoy proxy intercepts inbound and outbound traffic for its pod. That yields consistent behavior and strong isolation, but the model scales poorly. A cluster with many pods runs many Envoy containers, each consuming CPU and memory.

Ambient Mode replaces the sidecar per pod pattern with a layered data plane that separates Layer 4 (L4) and Layer 7 (L7) responsibilities. This separation allows the mesh to handle transport security independently from application logic.

Core Components

• ztunnel: A shared Layer 4 proxy that runs once per node. Written in Rust for extreme efficiency, ztunnel handles mutual TLS (mTLS), workload identity, basic traffic forwarding, and zero trust segmentation. All pods on the node participate in the mesh without injection or pod restarts.

• Waypoint proxies: Optional Layer 7 proxies deployed per service or per namespace. Waypoints provide routing, retries, timeouts, and authorization. Teams enable L7 features only where they are needed. These are based on Envoy but do not live inside the application pod.

Separating L4 and L7 clarifies responsibilities. ztunnel enforces identity and encryption at L4 using the HBONE (HTTP-Based Overlay Network Environment) protocol. Waypoints handle application level policies. This enables progressive adoption and reduces the blast radius of mesh changes. If a team only needs encryption, they never have to touch a Layer 7 proxy.

Latest Developments

Ambient Mode has matured quickly. Several recent improvements increase its practicality for production environments. By 2026, these features have become the standard for modern cloud native networking.

Ambient Mode now supports an in pod redirection mode that works with a wider range of Container Network Interfaces (CNIs). That reduces the need for special CNI features and improves compatibility with Cilium, Calico, and cloud vendor CNIs. This mechanism ensures that traffic is redirected to ztunnel without requiring complex host-level routing rules that once caused conflicts.

Because workloads do not contain sidecars, control plane and data plane upgrades do not require restarting application pods. ztunnel upgrades may reset long lived TCP connections, but pods remain running. This lowers upgrade risk for clusters with strict uptime requirements. The decouple between the application lifecycle and the proxy lifecycle is a significant win for platform stability.

Waypoint proxies integrate more cleanly with Kubernetes Gateway API resources. The project has expanded documentation, diagrams, and examples to help teams plan migrations and deployments. Using Gateway API as the primary configuration interface makes waypoint management feel like a native Kubernetes experience rather than a separate mesh-specific task.

Vendors and distributions are adding Ambient Mode support. That signals growing confidence in the architecture and makes enterprise adoption more feasible. Major cloud providers now offer Ambient as a managed option, further validating its readiness for high-scale environments.

Examples of Ambient Mode in Practice

To secure a namespace, a team only needs to label it.

apiVersion: v1
kind: Namespace
metadata:
  name: billing
  labels:
    istio.io/dataplane-mode: ambient

All pods in that namespace receive mTLS and identity enforcement through ztunnel. No pod restarts are required to enable L4 security.

If the payments service requires advanced traffic splitting or retries, a waypoint proxy can be deployed.

istioctl waypoint apply --name payments-waypoint --namespace billing

Only that service receives L7 features such as retries and authorization policies. Other services remain L4 only, saving significant memory across the cluster.

The transition is designed to be non-disruptive. A team can remove the sidecar injection label from a namespace and add the Ambient Mode label. Pods restart once to remove the sidecar, then operate under ztunnel. The team can then add waypoints later to enable L7 features for selected services without further pod disruptions.

Operational Concerns and Cautions

Ambient Mode reduces many operational headaches, but it introduces new considerations that platform teams must address.

Kubelet health probes often originate from the node as link local requests. Those node originated probes can bypass ztunnel or be affected by CNI kube proxy replacement. The result can be failing readiness or liveness checks even when the application is healthy.

Mitigations:

• Prefer in pod HTTP or gRPC probes when possible.
• If node originated probes are required, avoid CNI kube proxy replacement or apply the CNI settings that preserve probe behavior.

Ambient Mode relies on predictable traffic redirection. If the primary CNI intercepts traffic before ztunnel, the mesh may not function correctly. Cilium users should consider disabling kube proxy replacement or configuring socket level load balancing so it does not intercept mesh traffic before ztunnel.

Cilium NetworkPolicy enforces L3 and L4 rules. Istio’s AuthorizationPolicy enforces L7 rules. If these policies are not aligned, traffic may be allowed at one layer and denied at another. Because Ambient Mode encrypts L4 flows, Cilium cannot inspect L7 content for those flows once they enter the mTLS tunnel.

Best Practice:

• Use Cilium for coarse L3 and L4 guardrails.
• Use Istio for identity aware and L7 policies.
• Document ownership of each policy layer and avoid overlapping L7 enforcement across systems.

Some CNIs capture DNS via eBPF. Ambient Mode may also redirect DNS queries depending on configuration. If both systems attempt to manage DNS, name resolution failures or unexpected routing can occur.

Mitigations:

• Decide which system owns DNS capture and visibility.
• Test DNS resolution for cluster services, headless services, and external names under the combined configuration.

Cilium Hubble provides L3 and L4 visibility and can show L7 when traffic is unencrypted. Once Ambient Mode applies mTLS, Hubble sees encrypted flows and L7 visibility is reduced. The solution is to combine Hubble for network level telemetry with Istio telemetry for mesh level metrics and traces.

Benefits of Ambient Mode

When implemented carefully, Ambient Mode delivers several tangible advantages for the modern enterprise.

• Lower resource usage: A single ztunnel per node replaces many sidecars. This reduces CPU and memory consumption and lowers cloud spend for large clusters.
• Simpler upgrades: Upgrades no longer require restarting application pods. That reduces risk and improves availability for production workloads.
• Incremental adoption: Teams can enable L4 mesh features broadly and add L7 features selectively through waypoints. This supports progressive rollout and minimizes disruption.
• Cleaner separation of concerns: L4 identity and L7 policy are handled by distinct components. That separation aligns with platform engineering practices that favor clear ownership and minimal coupling.
• Reduced operational complexity: Removing sidecar injection eliminates a major source of operational issues. Teams spend less time debugging injection failures and more time delivering platform value.

Practical Checklist for Adoption

1. Validate CNI compatibility and choose safe kube proxy settings.
2. Decide which system owns DNS capture and test DNS paths.
3. Prefer in pod health probes or ensure node probes are preserved.
4. Define policy ownership for L3, L4, and L7 and document it.
5. Plan waypoint placement for services that need L7 features.
6. Test observability across Hubble and Istio telemetry to ensure coverage.
7. Stage upgrades in a non production environment and validate long lived connection behavior.

Where We Are Now

Istio Ambient Mode is a meaningful evolution in service mesh design. By removing sidecars and introducing a layered data plane, it reduces cost, simplifies operations, and enables incremental adoption. Recent improvements in compatibility, upgrade behavior, and documentation make Ambient Mode a viable option for production clusters.

Platform engineering teams should evaluate Ambient Mode with attention to CNI interactions, health probe behavior, DNS capture, and policy ownership. With careful planning and testing, Ambient Mode can provide a cleaner and more scalable approach to securing and managing service to service communication in Kubernetes.