Enabling Istio Sidecar Injection

At the moment, our demo application is running in the learning-tracker namespace and works quite well. However, to add some advanced features provided by the Service Mesh (such as mTLS, Authorization, Traffic Management, etc.), we need to enable Istio sidecar injection in this namespace. In Istio, this is done by adding a label to the namespace. This label tells Istio to inject the sidecar proxy into each pod that is created in this namespace.

To enable sidecar injection in the learning-tracker namespace, run the following command:

kubectl label namespace learning-tracker istio-injection=enabled

After adding the label to the namespace, nothing has changed yet in our demo application. The existing pods are still running without the sidecar proxy. To add the sidecar proxy to the existing pods, we need to restart them. To restart all deployments in the learning-tracker namespace, run:

kubectl rollout restart deployment -n learning-tracker -l app

This command restarts all deployments in the learning-tracker namespace that have the label app (in fact, this is every deployment we have there). After a few moments, all pods should be restarted, and you can verify that the sidecar proxy has been injected by running kubectl get pods:

NAME                                         READY   STATUS    RESTARTS      AGE
learning-tracker-api-6d449bb645-2b2cz        2/2     Running   0             27s
learning-tracker-api-6d449bb645-g5xj9        2/2     Running   2 (54s ago)   59s
learning-tracker-api-6d449bb645-qnvn4        2/2     Running   0             74s
learning-tracker-frontend-5c9c79ff64-jn5nh   2/2     Running   0             74s
learning-tracker-frontend-5c9c79ff64-ztvpb   2/2     Running   0             53s
mariadb-568f9dc44c-g86z8                     2/2     Running   0             74s

As you can see, each pod now has two containers: the application container and the Istio sidecar proxy (Envoy). The sidecar proxy is responsible for intercepting all incoming and outgoing traffic and applying the rules and policies defined in Istio. You can also inspect the logs of the sidecar proxy by running:

kubectl logs <pod-name> -c istio-proxy

When you open the demo application again in your browser, you should still see the same functionality as before. However, now Istio is managing the traffic between the components of our demo application. When opening Kiali again, you should now see some information about the services and their communication.

At this point, we have successfully enabled Istio sidecar injection in our demo application and restarted the pods to inject the sidecar proxy. In the next steps, we will configure Istio to enforce mTLS between the services and set up some basic authorization rules.