How Istio’s Sidecar Hijacks Traffic: A Deep Dive into Service Mesh Mechanics

What is Istio

Istio is an open‑source service mesh that provides a unified way to connect, protect, monitor, and manage micro‑service‑based applications. It solves the complexity of service‑to‑service communication by offering load balancing, mutual authentication, observability, and resilience features such as retries and circuit breaking.

What is a Sidecar

A sidecar is a design pattern where an auxiliary container runs alongside the business container. All inbound and outbound traffic passes through the sidecar, which can implement functions like circuit breaking, rate limiting, monitoring, and logging, keeping the business container lightweight.

In Istio, the sidecar uses Envoy, a high‑performance proxy that supports HTTP/1.1, HTTP/2, gRPC, TCP, load balancing, circuit breaking, rate limiting, and monitoring. Istiod updates Envoy configuration via a gRPC stream.

Startup Method

When a namespace has the label istio-injection=enabled, Istio’s mutating admission webhook automatically injects the Envoy sidecar and an init container into each pod. The init container configures the pod’s network namespace, allowing the sidecar to intercept traffic.

Traffic Hijacking Method

Istio inserts iptables rules that redirect traffic to the sidecar. For example, traffic from a test pod to an nginx service is first intercepted by the test pod’s sidecar, then forwarded to the nginx pod’s sidecar, and finally delivered to the nginx container.

Outbound traffic from the test pod matches the ISTIO_OUTPUT chain.

Because the destination is not a loopback address and the owner is not Envoy, the traffic is sent to the ISTIO_REDIRECT chain.

The ISTIO_REDIRECT chain DNATs the traffic to port 15001, where Envoy listens.

Envoy forwards the request to the nginx pod IP 10.244.0.73.

Inbound traffic to the nginx pod follows the ISTIO_INBOUND chain and is DNATed to port 15006, where the nginx pod’s sidecar processes it.

The sidecar then forwards the request to the nginx container on port 80.

xDS

Envoy obtains its configuration dynamically from Istiod via the xDS APIs. The main discovery services are:

CDS – Cluster Discovery Service

EDS – Endpoint Discovery Service

LDS – Listener Discovery Service

RDS – Route Discovery Service

SDS – Secret Discovery Service

HDS – Health Discovery Service

ADS – Aggregated Discovery Service

Listeners define which ports Envoy listens on; routes map listeners to virtual hosts; clusters define upstream services; endpoints provide the actual IP addresses of those services.

Data Sources

Istiod watches Kubernetes resources (Services, Endpoints, and Istio CRDs) and pushes the combined configuration to each sidecar via a gRPC stream.

kubectl -n test get svc nginx

NAME    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
nginx   ClusterIP   10.102.168.134   <none>        80/TCP    112m

kubectl -n test get endpoints nginx

NAME    ENDPOINTS            AGE
nginx   10.244.0.73:80   112m

Configuration Inspection

You can view the Envoy configuration through its admin API or with istioctl:

kubectl port-forward pod/nginx-7c79c4bf97-7985c 15000:15000
curl http://localhost:15000/config_dump

Example commands to inspect listeners, routes, clusters, and endpoints:

istioctl -n test proxy-config listener test-pod --port 15001

istioctl -n test proxy-config listener test-pod --port 80 --address 10.102.168.134

istioctl -n test proxy-config route test-pod | grep nginx.test.svc.cluster.local

istioctl -n test proxy-config cluster test-pod --fqdn "outbound|80||nginx.test.svc.cluster.local" -oyaml

istioctl -n test proxy-config endpoint test-pod --cluster "outbound|80||nginx.test.svc.cluster.local" -oyaml

Traffic Flow Diagram

The following diagram visualizes the request flow from the test pod to the nginx service.

Additional Resources

Original article: https://www.cnblogs.com/daemon365/p/18187995