# Istio Not Creating Sidecars

When you enable sidecar injection but pods still come up **without** the `istio-proxy` container (for example `kubectl get pod` shows `READY 1/1` instead of `2/2`), work through the checks below in order. The first one resolves the large majority of cases.

---

## 1. Is the Namespace Labeled for Injection?

Istio only injects sidecars into namespaces that carry the injection label. This is the most common cause.

```bash
kubectl get namespace <your-namespace> --show-labels
```

The output must include `istio-injection=enabled` (for the default revision) or a `istio.io/rev=<revision>` label (for a revisioned install). If it is missing, add it:

```bash
kubectl label namespace <your-namespace> istio-injection=enabled
```

:::note
Injection happens **at pod creation time**. Existing pods are not retrofitted - restart the workload after labeling the namespace:

```bash
kubectl rollout restart deployment/<your-deployment> -n <your-namespace>
```

:::

---

## 2. Is the Sidecar Injector Webhook Present and Healthy?

The injector runs as a mutating admission webhook. Confirm it exists:

```bash
kubectl get mutatingwebhookconfiguration | grep istio
```

You should see a configuration such as `istio-sidecar-injector` (or `istio-revision-tag-default` for tag-based installs). Inspect it and confirm the `istiod` control-plane pods are running:

```bash
kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml
kubectl get pods -n istio-system -l app=istiod
```

The `istiod` pod(s) must be `Running`. The webhook backs onto this service, so if `istiod` is down, no injection happens.

---

## 3. Does the Pod Have the `istio-proxy` Container?

```bash
kubectl describe pod <your-pod> -n <your-namespace>
```

Under the **Containers:** section, look for an `istio-proxy` container alongside your application container. If it is present, injection worked. If the pod shows `2/2` Ready, the sidecar is running.

You can also confirm whether the namespace selection would have injected a given pod by checking the namespace label (Step 1) against the webhook's `namespaceSelector`.

---

## 4. Check the Injection Configuration and Logs

If the namespace is labeled, the webhook exists, and `istiod` is healthy but sidecars still are not injected, inspect the injection template and the control-plane logs:

```bash
# Injection template / config
kubectl get configmap istio-sidecar-injector -n istio-system -o yaml

# istiod logs - look for webhook/injection errors
kubectl logs -n istio-system -l app=istiod --tail=100
```

Common issues surfaced here:

- A `neverInjectSelector` / `alwaysInjectSelector` or pod annotation `sidecar.istio.io/inject: "false"` explicitly disabling injection.
- A webhook `failurePolicy` or certificate problem preventing the API server from reaching `istiod`.
- A revision mismatch - the namespace points at a revision (`istio.io/rev`) that is not installed.

---

> Fix the cause, then recreate the workload. Sidecars are injected only when a pod is **created**, so always restart the deployment after changing labels or injection settings.

---