Cloud Native 6 min read

Understanding Istio Sidecar Injection: The istio-sidecar-injector Component

This article explains how Istio injects sidecar containers into user‑space Pods using the istio‑sidecar‑injector component, covering automatic and manual injection methods, the underlying MutatingAdmissionWebhook configuration, the initContainer and sidecar containers added, and the associated ConfigMap and volume setups.

Cloud Native Technology Community
Cloud Native Technology Community
Cloud Native Technology Community
Understanding Istio Sidecar Injection: The istio-sidecar-injector Component

Istio injects a sidecar container into user‑space Pods to join the service mesh. Two injection methods are available: automatic injection via Kubernetes Dynamic Admission Webhooks and manual injection using istioctl kube-inject .

The injection works by modifying the Pod definition to add two containers: an initContainer named istio-init that configures iptables, and a sidecar container named istio-proxy that runs pilot-agent and envoy .

Istio uses a MutatingAdmissionWebhook (the istio-sidecar-injector service) to perform automatic injection. The webhook is configured with a MutatingWebhookConfiguration resource that watches CREATE operations on Pods in namespaces labeled istio-injection=enabled . Example configuration:

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: istio-sidecar-injector
webhooks:
- name: sidecar-injector.istio.io
  clientConfig:
    service:
      name: istio-sidecar-injector
      namespace: istio-system
      path: /inject
  namespaceSelector:
    matchLabels:
      istio-injection: enabled
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    operations: ["CREATE"]
    resources: ["pods"]

The injector pod itself mounts a projected volume that provides the injection template stored in a ConfigMap ( istio-sidecar-injector ). The template defines the initContainer and sidecar specifications, including images, capabilities, volume mounts, and probes. A shortened excerpt of the template:

policy: enabled
template: |-
  initContainers:
  - name: istio-init
    image: "docker.io/istio/proxy_init:1.1.0"
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
  containers:
  - name: istio-proxy
    image: [[ annotation .ObjectMeta `sidecar.istio.io/proxyImage` "docker.io/istio/proxyv2:1.1.0" ]]
    args:
    - proxy
    - sidecar
    readinessProbe:
      httpGet:
        path: /healthz/ready
        port: [[ annotation .ObjectMeta `status.sidecar.istio.io/port` 0 ]]
    volumeMounts:
    - mountPath: /etc/istio/proxy
      name: istio-envoy
    - mountPath: /etc/certs/
      name: istio-certs
      readOnly: true
  volumes:
  - name: istio-envoy
    emptyDir:
      medium: Memory
  - name: istio-certs
    secret:
      optional: true
      secretName: istio.default

The sidecar injector also defines two volumes for the istio-proxy container: an emptyDir volume ( istio-envoy ) for Envoy configuration, and a secret volume ( istio-certs ) that provides TLS certificates, typically mounted at /etc/certs/ .

Further articles will dive deeper into the istio-proxy sidecar behavior.

kubernetesistioservice meshConfigMapMutatingWebhookSidecar Injection
Cloud Native Technology Community
Written by

Cloud Native Technology Community

The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.