Deep Dive into Istio’s Networking: How Sidecar Injection Works in Kubernetes

Istio Networking Basics

Istio is a platform‑neutral service mesh that enhances security, service discovery, request routing, and reliable communication between microservices in a Kubernetes cluster. It consists of a data plane (Envoy sidecar proxies) and a control plane (istiod).

Data Plane

The data plane is made up of Envoy sidecar containers injected into each pod. These sidecars manage all network traffic between services and collect telemetry data.

Control Plane

The control plane, represented by the istiod binary, translates high‑level routing rules into Envoy configuration, distributes it to sidecars, and provides security features such as identity and certificate management.

Sample Environment Setup

To demonstrate Istio, a local sandbox is created using minikube and istioctl. The following commands provision a Kubernetes 1.22.2 cluster and install Istio:

minikube start --memory=4096 --cpus=2 --disk-size='20gb' --kubernetes-version=1.22.2 --driver=hyperkit -p istio-demo

# Deploy Istio operator
istioctl operator init
# Inject operator configuration
cat << EOF | kubectl apply -f -
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-control-plane
  namespace: istio-system
spec:
  profile: minimal
  meshConfig:
    accessLogFile: /dev/stdout
    enableAutoMtls: true
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: 'true'
        ISTIO_META_DNS_AUTO_ALLOCATE: 'true'
EOF

After installing Istio, a sample sleep application is deployed with sidecar injection enabled:

# Create apps namespace
kubectl create ns apps
# Label namespace for auto‑injection
kubectl label ns apps istio-injection=enabled
# Deploy sleep app
cat << EOF | kubectl apply -n apps -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
spec:
  ports:
  - name: http
    port: 80
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: secret-volume
          mountPath: /etc/sleep/tls
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
EOF

Verification of the init and sidecar containers can be done with:

kubectl get po -l app=sleep -n apps -o jsonpath='{range .items[*]}{range @.status.containerStatuses[*]}{.name},{"ready="}{.ready},{"started="}{.started}{"
"}{end}{range @.status.initContainerStatuses[*]}{.name},{"ready="}{.ready},{"terminated="}{.state.terminated.reason}{end}' | sort

The output shows the istio-init container has completed and the istio-proxy container is ready.

Sidecar and Init Containers

Istio injects two containers into each pod:

istio-init : Configures iptables so that the Envoy sidecar can intercept inbound and outbound traffic. It runs as an init container with limited privileges (only NET_ADMIN and NET_RAW capabilities).

istio-proxy : Runs the Envoy proxy (extended version) with a readiness probe that checks /healthz/ready on port 15021.

Both containers share the same image docker.io/istio/proxyv2:1.11.4. The init container runs as root to modify iptables, while the proxy runs as a non‑root user (UID 1337) with a read‑only filesystem.

Sidecar Injection Methods

Istio supports manual and automatic sidecar injection.

Manual Injection

Use istioctl kube-inject to modify manifests before applying them:

istioctl kube-inject -f application.yaml | kubectl apply -f -

Or:

kubectl apply -f <(istioctl kube-inject -f application.yaml)

Automatic Injection

Enabled by labeling a namespace with istio-injection=enabled or annotating a pod with sidecar.istio.io/inject="true". Istio registers a mutating admission webhook ( istio-sidecar-injector) that adds the init and sidecar containers to pod specifications during creation.

The webhook configuration can be inspected with:

kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml

Injection rules consider both namespace selectors and object annotations to determine whether a sidecar should be added.

Conclusion

This article covered Istio’s networking fundamentals, the composition of its data and control planes, and demonstrated how sidecar and init containers are injected into Kubernetes pods using both manual and automatic methods. Future posts will explore traffic management configuration and iptables handling.