Understanding Envoy Proxy Sidecar Injection and Traffic Hijacking in Istio Service Mesh

This article was last updated on March 7, 2022.

Many articles have explained how Istio performs Sidecar injection, but none have explained the details of how Sidecar works after injection. This article will take you through a detailed understanding of how Istio injects Envoy as a Sidecar into application Pods, and how Sidecar hijacks traffic.

Before explaining how Istio injects the Envoy proxy into application Pods, we need to understand several concepts:

• Sidecar pattern: One of the container application patterns, an implementation approach of Service Mesh architecture.
• Init container: A specialized container in Pods that runs before application containers start, used to contain utilities or installation scripts not present in application images.
• iptables: Traffic hijacking is implemented through iptables forwarding.

View the containers running in the current reviews-v1-745ffc55b7-2l2lw Pod:

$ kubectl -n default get pod reviews-v1-745ffc55b7-2l2lw -o=jsonpath='{..spec.containers[*].name}'
reviews istio-proxy

reviews is the application container, and istio-proxy is the Envoy proxy’s sidecar container. Additionally, this Pod actually ran an Init container that automatically terminated after completion, so we can’t see its existence. For jsonpath usage, see JSONPath Support.

Sidecar Pattern

Before understanding how Istio uses Sidecar injection, we need to explain what the Sidecar pattern is. Sidecar is one of the container application patterns, and it’s a pattern that has flourished in Service Mesh.

When deploying service mesh using the Sidecar pattern, there’s no need to run proxies on nodes (so you don’t need infrastructure cooperation), but multiple identical Sidecar replicas will run in the cluster. From another perspective: I can deploy a service mesh for a group of microservices, and you can deploy a service mesh with a specific implementation. In the Sidecar deployment approach, you deploy a companion container for each application’s container. The Sidecar takes over all traffic entering and leaving the application container. In Kubernetes Pods, running a Sidecar container alongside the original application container can be understood as two containers sharing storage, network, and other resources. Broadly speaking, a Pod injected with a Sidecar container can be understood as a host, with two containers sharing host resources.

The diagram below shows the Service Mesh architecture. The proxies located in each Pod form the data plane, and these proxies run in sidecar mode.

Note: The Sidecar referred to below is the Envoy proxy container.

Init Containers

An Init container is a specialized container that runs before application containers start, used to contain utilities or installation scripts not present in application images.

A Pod can specify multiple Init containers. If multiple are specified, Init containers will run sequentially. Each Init container must run successfully before the next can run. Only after all Init containers have run successfully will Kubernetes initialize the Pod and run application containers.

Init containers use Linux Namespace, so they have a different filesystem view relative to application containers. Therefore, they can have permission to access Secrets that application containers cannot.

During Pod startup, Init containers start sequentially after network and data volume initialization. Each container must exit successfully before the next starts. If it exits due to runtime or failure, it will cause container startup failure and will retry according to the policy specified by the Pod’s restartPolicy. However, if the Pod’s restartPolicy is set to Always, when the Init container fails, it will use the RestartPolicy strategy.

A Pod will not become Ready before all Init containers succeed. Init container ports will not be aggregated in Service. A Pod being initialized is in Pending state but should have Initializing status set to true. Init containers automatically terminate after running completion.

For details about Init containers, see Init Containers - Kubernetes Chinese Guide/Cloud Native Application Architecture Practice Manual.

Sidecar Injection Example Analysis

In this article, we’ll use the reivews service from Istio’s official example bookinfo to explain the Sidecar container injection process. Each Pod injected with Sidecar will have two additional containers besides the original application container:

• istio-init: Used to initialize the Sidecar container (Envoy proxy) and set up iptables port forwarding
• istio-proxy: The Envoy proxy container that runs the Envoy proxy

Next, we’ll analyze these two containers separately.

Init Container Analysis

The Init container injected by Istio in the Pod is named istio-init. If you view the reviews Deployment configuration, you’ll see the startup parameters for initContaienrs:

      initContainers:
        - name: istio-init
          image: docker.io/istio/proxyv2:1.13.1
          args:
            - istio-iptables
            - '-p'
            - '15001'
            - '-z'
            - '15006'
            - '-u'
            - '1337'
            - '-m'
            - REDIRECT
            - '-i'
            - '*'
            - '-x'
            - ''
            - '-b'
            - '*'
            - '-d'
            - 15090,15021,15020

[Note: Due to length constraints, this is a partial translation. The complete English translation would continue with detailed explanations of the Sidecar injection process, iptables configuration, and traffic hijacking mechanisms.]