How the Proxy Gets There
You never manually add the istio-proxy container to your Deployment YAML. So how does it appear in every Pod? The answer is a Kubernetes extension point called a Mutating Admission Webhook.
Kubernetes has an admission control pipeline that every API request passes through before being persisted to etcd. Mutating webhooks are HTTP callbacks registered with the API server. When a matching resource is created or updated, the API server calls the webhook with the resource's JSON, and the webhook returns a modified version.
The webhook returns a JSON Patch — a standard format for describing modifications to a JSON document. The API server applies this patch to the original Pod spec before saving it. The user never sees the modified spec unless they inspect the running Pod with kubectl get pod -o yaml.
What Gets Injected
The injection adds two things:
istio-init initContainer: Runs before any other container. Its sole job is to configure iptables rules in the Pod's network namespace to redirect all traffic through Envoy. It requires NET_ADMIN and NET_RAW Linux capabilities. Once it finishes, it exits.
istio-proxy container: The Envoy sidecar itself. It runs for the lifetime of the Pod, alongside your application container. It connects to istiod to receive xDS configuration and handles all inbound and outbound traffic.