Injecting sidecar proxies

Anthos Service Mesh uses sidecar proxies to enhance network security, reliability, and observability. These functions are abstracted away from the application's primary container and implemented in a common out-of-process proxy (the sidecar), delivered as a separate container in the same Pod. This provides the Anthos Service Mesh's features without redesigning your production applications to participate in a service mesh.

Automatic sidecar proxy injection (auto-injection) occurs when Anthos Service Mesh detects a namespace label you configure for the workload's Pod. The proxy intercepts all inbound and outbound traffic to the workloads and communicates with Anthos Service Mesh.

Permissions required for these tasks

To perform the tasks on this page, you must have the roles/container.clusterAdmin or a higher role. See Google Kubernetes Engine roles for details on the permissions included in this role.

Enabling automatic sidecar injection

The recommended way to inject sidecar proxies is to use the webhooks-based automatic sidecar injector, although you can manually update your Pods' Kubernetes configuration. To enable auto-injection, you add a revision label to your namespace. The label that you add depends on whether you deployed managed Anthos Service Mesh or installed the in-cluster control plane. The revision label is used by the sidecar injector webhook to associate injected sidecars with a particular control plane revision.

To enable auto-injection:

In-cluster

Use the following command to locate the revision label on istiod:

kubectl -n istio-system get pods -l app=istiod --show-labels

The output looks similar to the following:

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586

In the output, under the LABELS column, note the value of the istiod revision label, which follows the prefix istio.io/rev=. In this example, the value is asm-1106-2.

Apply the revision label to namespaces and remove the istio-injection label (if it exists). In the following command, NAMESPACE is the name of the namespace where you want to enable auto-injection, and REVISION is the revision label you noted in the previous step.
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
You can ignore the message "istio-injection not found" in the output. That means that the namespace didn't previously have the istio-injection label, which you should expect in new installations of Anthos Service Mesh or new deployments. Because auto-injection fails if a namespace has both the istio-injection and the revision label, all kubectl label commands in the Anthos Service Mesh documentation include removing the istio-injection label.
Restart the affected pods, using the steps in the next section.

Managed service mesh

Apply the following revision label to your namespaces and remove the istio-injection label (if it exists). In the following command, replace NAMESPACE with the name of the namespace where you want to enable auto-injection:
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=asm-managed-rapid --overwrite
```
You can ignore the message "istio-injection not found" in the output. That means that the namespace didn't previously have the istio-injection label, which you should expect in new installations of Anthos Service Mesh or new deployments. Because auto-injection fails if a namespace has both the istio-injection and the revision label, all kubectl label commands in the Anthos Service Mesh documentation include removing the istio-injection label.
Restart the affected pods, using the steps in the next section.

If you also deployed the optional Google-managed data plane, annotate the demo namespace as follows:

kubectl annotate --overwrite namespace YOUR_NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

Restart Pods to update sidecar proxies

With automatic sidecar injection, you can update the sidecars for existing Pods with a Pod restart:

How you restart Pods depends on if they were created as part of a Deployment.

If you used a Deployment, restart the Deployment, which restarts all Pods with sidecars:
```
kubectl rollout restart deployment -n YOUR_NAMESPACE
```
If you didn't use a Deployment, delete the Pods, and they are automatically recreated with sidecars:
```
kubectl delete pod -n YOUR_NAMESPACE --all
```
Check that all the Pods in the namespace have sidecars injected:
```
kubectl get pod -n YOUR_NAMESPACE
```
In the following example output from the previous command, notice that the READY column indicates there are two containers for each of your workloads: the primary container and the container for the sidecar proxy.
```
NAME                    READY   STATUS    RESTARTS   AGE
YOUR_WORKLOAD           2/2     Running   0          20s
...
```

What's next

Learn more about: