Revisiting the Blog App – Implementing Traffic Management, Security, and Observability with Istio

Since we discussed the Blog App previously, let’s look at the services and their interactions again:

Figure 15.1 – The Blog App and its services and interactions

So far, we’ve created CI and CD pipelines for building, testing, and pushing our Blog App microservices containers using GitHub Actions, deploying them using Argo CD in a GKE cluster.

As you may recall, we created the following resources for the application to run seamlessly:

• MongoDB: We deployed an auth-enabled MongoDB database with root credentials. The credentials were injected via environment variables sourced from a Kubernetes Secret resource. To persist our database data, we created a PersistentVolume mounted to the container, which we provisioned dynamically using a PersistentVolumeClaim. As the container is stateful, we used a StatefulSet to manage it and, therefore, a headless Service to expose the database.

• Posts, reviews, ratings, and users: The posts, reviews, ratings, and users microservices interacted with MongoDB through the root credentials that were injected via environment variables sourced from the same Secret as MongoDB. We deployed them using their respective Deployment resources and exposed all of them via individual ClusterIP Services.

• Frontend: The frontend microservice does not need to interact with MongoDB, so there was no interaction with the Secret resource. We also deployed this service using a Deployment resource. As we wanted to expose the service on the internet, we created a LoadBalancer Service for it.

We can summarize them with the following diagram:

Figure 15.2 – Blog App – Kubernetes resources and interactions

Now that we understand the application, let’s understand what a service mesh is and how it is beneficial in this use case.