Exploring Istio Ambient Mode: Understanding the Role of Istio-CNI

This article is part of my personal project, Smart-cash. Previous posts covered topics such as:

• Deploying AWS and Kubernetes resources with Terraform and GitHub Actions
• Configuring logging with Fluent Bit and CloudWatch
• Distributed tracing with Jaeger and OpenTelemetry.

The Basics

Service Mesh: A dedicated infrastructure layer that manages service-to-service communication. It provides traffic routing, observability (metrics, logs, traces), security (mTLS), and resilience,all transparently.

Why Use a Service Mesh?

It simplifies microservices complexity by centralizing traffic control, enforcing security using mTLS, and enabling good observability. In my experience, it is good for environments with many interdependent services or strict traffic policies. For simple applications, it can add unnecessary overhead.

Istio: An open-source service mesh that integrates seamlessly with Kubernetes. It offers two deployment models:

• The sidecar mode, adds an Envoy proxy to every pod.
• The Ambient mode, eliminates sidecars and uses daemons running in nodes for traffic interception.

Istio Sidecar vs. Ambient Mode

In sidecar mode, Istio injects an Envoy proxy container into every pod that joins the mesh. You can configure this at the namespace or pod level. This proxy intercepts all inbound and outbound traffic. 3 main CRD can be highlighted:

• VirtualService: Defines routing rules (path-based routing, retries, timeouts).
• Gateway: Exposes services externally.
• DestinationRule: Controls how to serve the traffic to the services (load balancing, circuit breaking).

In Ambient mode, Istio removes sidecars. Instead, it uses two daemons running in each node to intercept and secure traffic. This is an innovative way that uses kernel-level features.

Here the main components:

• ztunnel Secures traffic and authenticates workloads within the mesh, manages mTLS, authentication, L4 authorization, and telemetry. This is only for L3 and L4 traffic; this doesn't terminate HTTP traffic. Ztunnel runs on every node.

• IstioCNI Detects when a new pod is created and configures iptables rules to redirect traffic to ztunnel.

• waypoint Provides L7 traffic management, HTTP routing, retries, etc. This is an optional component that is deployed per namespace or service.

Installing Istio

Installation will be done using Helm and Flux. For the detailed YAML manifest used, you can check these links:

• Flux-Source Istio Helm repo
• Flux-Helm-Release Istio Base (CRDs)
• Flux-Helm-Release Istiod (Control Plane). Here, we need to set the profile to ambient, check the values
• Flux-Helm-Release Istio-cni
• Flux-Helm-Release Istio-ztunnel

You should see the pods in the istio-system namespace. Notice that only the control plane runs as a deployment; other components are daemon-sets.

Kiali is a useful tool for checking and visualizing the mesh. You can install using the documentation. For this case, the services graph looks like:

Add the following label to the namespace you want to include in the mesh. Here, we added it to the develop namespace:

istio.io/dataplane-mode=ambient

How does it work internally?

When a pod is created istio-cni automatically:

• Detects the pod via Kubernetes CNI events
• Enters the pod’s network namespace
• Injects iptables rules to redirect inbound and outbound traffic to ztunnel

Let's check this in detail

WITHOUT Istio enabled

Inside one node,list the containers that are running:

crictl pods --namespace develop

We need to go inside the pod's network namespace and check the iptables rules. For that, we need to get the Pause container associated

sudo crictl inspectp 07689efcedf1f | jq -r '.info.pid'
sudo lsns -t net

With the PID of the Pause container, you can enter the network namespace or run a command directly:

sudo nsenter -t 18757 -n iptables -t nat -L | grep REDIRECT

The output should not show any redirection rules.

We can confirm that there are no redirection rules.

WITH Istio enabled

We can run the same commands to go inside pod network namespace, but when we list the IP tables rules, we will see these redirection rules:

Those ports are related to Istio Ztunnel, which are listed in Documentation.

With this, all traffic inside the pod is redirected to a ztunnel proxy, which manages it. This eliminates the need for a sidecar container.

IstioCNI plays a key role in Ambient Mode. It replaces the sidecar injection step by configuring traffic redirection at the network namespace.

In the next post, we will check mTLS and custom configurations.