Injecting sidecar proxies

Anthos Service Mesh uses sidecar proxies to enhance network security, reliability, and observability. With Anthos Service Mesh, these functions are abstracted away from the application's primary container and implemented in a common out-of-process proxy delivered as a separate container in the same Pod. To take full advantage of Anthos Service Mesh's features, when you deploy or redeploy workloads, you inject a sidecar proxy into 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

You can inject a sidecar proxy manually by updating your Pods' Kubernetes configuration, or you can use the webhooks-based automatic sidecar injection. By default, sidecar auto-injection is disabled for all namespaces. To enable auto-injection:

kubectl label namespace NAMESPACE istio-injection=enabled --overwrite

where NAMESPACE is the name of the namespace for your application's services or default if you didn't explicitly create a namespace.

Because sidecars are injected when Pods are created, you must restart any running Pods for the change to take effect.

Manual sidecar injection

To inject sidecars manually, refer to Installing the sidecar.

Updating sidecars for existing Pods

Warning: Unless you have a load balancer or router setup for blue-green deployments, make sure you test restarting Pods in a staging environment to verify that your services can handle any potential traffic interruption.

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.

1. If you used a Deployment, restart the Deployment, which restarts all Pods with sidecars:

   kubectl rollout restart deployment
   

   If you didn't use a Deployment, delete the Pods, and they are automatically recreated with sidecars:

   kubectl delete pod -n YOUR_NAMESPACE --all

2. Check that all the Pods in the namespace have sidecars injected:

   kubectl get pod -n YOUR_NAMESPACE --all

   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:

• Deploying workloads