🐳How to Enable Sidecar Injection in Istio at Namespace and Deployment Level
Istio uses sidecar proxies (Envoy) to manage service-to-service communication, security, and observability. For these proxies to work, they must be injected into your application pods. Istio provides two ways to enable this: at the namespace level (automatic injection for all pods) or at the deployment level (injection for specific workloads).
When sidecar injection is enabled:
- An Envoy proxy container is added alongside your application container in the same pod.
- This proxy intercepts and manages all inbound and outbound traffic.
- You can choose to inject sidecars automatically or manually.
By default, Istio uses automatic injection with the help of Kubernetes mutating webhooks.
✅2. Enabling Sidecar Injection at Namespace Level
If you want all deployments in a namespace to have sidecars, label the namespace:
kubectl label namespace <namespace> istio-injection=enabled
For example, if your namespace is default:
kubectl label namespace default istio-injection=enabled
Now, every new pod created in this namespace will automatically have the Envoy sidecar injected.
⚠️ Existing pods are not modified. You need to redeploy them:
kubectl rollout restart deployment <deployment-name> -n <namespace>
Sometimes you don’t want all workloads in a namespace to get sidecars. In that case, you can enable injection per deployment using pod annotations.
Edit your deployment YAML and add this annotation under metadata:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
namespace: default
labels:
app: myapp
annotations:
sidecar.istio.io/inject: “true”
spec:
replicas: 2
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
– name: myapp
image: myapp:latest
This ensures that only the myapp pods get the Envoy sidecar, even if the namespace doesn’t have the istio-injection=enabled label.
✅4. Verifying Sidecar Injection
To check if a sidecar was injected, run:
kubectl get pods -n <namespace>
Then describe a pod:
kubectl describe pod <pod-name> -n <namespace>
You should see two containers in the pod:
Your application container
The Envoy proxy container (named
istio-proxy)
Best Practices
- Use namespace-level injection for environments where all services should be part of the mesh.
- Use deployment-level injection when only selected workloads should join the mesh.
- After enabling injection, always restart your pods so the sidecars are included.
- Monitor your mesh with istioctl proxy-status to confirm proxies are connected to Istio control plane.
🎯 Conclusion
Sidecar injection is a core part of Istio’s service mesh functionality. By enabling it at the namespace or deployment level, you gain flexibility in deciding which workloads participate in the mesh. Namespace-level injection is easier for full environments, while deployment-level injection gives finer control over specific services.
🎯 Keywords
istio sidecar injection, enable istio sidecar, istio namespace injection, istio deployment injection, automatic sidecar injection, manual sidecar injection, istio kubernetes tutorial, istio service mesh sidecar, kubernetes istio sidecar example, configure istio injection, istio proxy sidecar, istio sidecar setup, istio namespace configuration, istio deployment configuration, istio service mesh guide