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.
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.defaultThe 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.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.