Life of a Packet in ISTIO — Part 1

Topics — Part 1 (Traffic Interception)

  1. Sidecar injection
  2. Init-container iptable configuration
  3. Traffic Interception in SideCar Proxy

Topics — Part 2 (SideCar proxy config)

  1. Envoy proxy configuration introduction
  2. Proxy Configuration — Inbound and outbound

Topics — Part 3 (Architecture)

  1. Pilot
  2. Citadel
  3. Galley

Topics — Part 4 (Traffic Management)

  1. Ingress Gateway
  2. Egress Gateway
  3. Gateway, VirtualService, and Destination rules

Topics — Part 5 (Observability)

  1. Metrics
  2. Tracing

Topics — Part 6 (Security)

  1. TLS

What is a Service Mesh?

What is Istio?

How it Works

I’ll be using the book info application from the ISTIO documentation as an example to explore and explain ISTIO.

Traffic routing without ISTIO

A Kubernetes service can be used to easily expose an application deployed on a set of pods using a single endpoint. Services keep track of the changes in IP addresses and DNS names of the pods and expose them to the end-user as a single IP or DNS.

Traffic routing with ISTIO

Envoy Proxy is deployed as a sidecar to the relevant service in the same Kubernetes pod. A sidecar is just a container that runs on the same Pod as the application container, because it shares the same volume and network as the main container, it can “help” or enhance how the application operates.

Book info app with ISTIO

SideCar Injection

In simple terms, sidecar injection is adding the configuration of additional containers to the pod template. The added containers needed for the Istio service mesh are,

istio-proxy (sideCar)

istio-proxy This is the actual sidecar proxy (based on Envoy).


istio-init This init container is used to set up the iptables rules so that inbound/outbound traffic will go through the sidecar proxy. An init container is different than an app container in the following ways:

  • It runs before an app container is started and it always runs to completion.
  • If there are many init containers, each should be complete with success before the next container is started.

istio-init iptable rules

How does the sidecar proxy grab the inbound and outbound traffic to and from the container? It is done by the iptable rules created by theistio-init container command.

SideCar injection methods

In the manual injection method, you can use istioctl to modify the pod template and add the configuration of the two containers previously mentioned. For both manual as well as automatic injection, Istio takes the configuration from the istio-sidecar-injector configuration map (configmap) and the mesh’s istio configmap.

  1. First, the istio-sidecar-injector mutating configuration injected during the Istio installation process (shown below) sends a webhook request with all pod information to the istiod controller.
  2. Next, the controller modifies the pod specification in runtime introducing an init and sidecar container agents to the actual pod specification.
  3. Then, the controller returns the modified object back to the admission webhook for object validation.
  4. Finally after validation, the modified pod specification is deployed with all the sidecar containers.

Traffic Interception (Inbound traffic)

TCP requests that are sent or received from the Pod will be hijacked by iptables. After the inbound traffic is hijacked, it is processed by the Inbound Handler and then forwarded to the application container for processing.

  • Applications binding only to lo will receive traffic from other pods, when otherwise this is not allowed.
  • Applications binding only to eth0 will not receive traffic.

Traffic Interception (Outbound traffic)

The outbound traffic is hijacked by iptables and then forwarded to the Outbound Handler for processing.

iptable analysis

Following are the NAT table rules that handle inbound and outbound traffic routing.

Outbound Traffic Routing

  1. Product Page service sends requests to the reviews service which is intercepted by netfilter again and forwarded to the export traffic OUTPUT chain
  2. OUTPUT chain forwarding traffic to ISTIO_OUTPUT chain
  3. Traffic that sends non-localhost requests and is istio proxy user space is forwarded to ISTIO_REDIRECT chain
  4. ISTIO_REDIRECT chain is directly redirected to the 15001 outlet traffic port monitored by envoy
  5. After a series of export traffic governance actions, envoy continues to send response data, which will be intercepted by netfilter and forwarded to the export traffic OUTPUT chain
  6. OUTPUT chain forwarding traffic to ISTIO_OUTPUT chain
  7. The traffic is directly returned to the POSTROUTING and then reaches the Reviews service.
  1. The product page service sends a TCP connection request to the reviews service
  2. The request enters the Pod kernel space where the reviews service is located, is intercepted by netfilter, passes through the PREROUTING chain, and then forwarded to the ISTIO_INBOUND chain
  3. ISTIO_INBOUND chain is defined by this rule — A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT intercepts and forwards to ISTIO_IN_REDIRECT
  4. ISTIO_IN_REDIRECT chain is directly redirected to the 15006 inlet traffic port monitored by the envoy.
  5. After a series of inbound traffic governance actions, the envoy sends a TCP connection request to review the service. This step belongs to outbound traffic for the envoy and will be intercepted by netfilter and forwarded to the outbound traffic OUTPUT chain
  6. OUTPUT chain forwarding traffic to ISTIO_OUTPUT chain
  7. The destination is localhost, which can’t be matched to the forwarding rule chain. RETURN directly to the next chain.
  8. The request from sidecar arrives at the review service 9080 port



This article does not provide any technical advice or recommendation; if you feel so, it is my personal view, not the company I work for.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store