I’ve finally been looking into Kubernetes properly since of late. When learning about containers, pods and services, what pretty much every doc, article, video tells is that,

1. Containers in the same pod can just use localhost and the port to communicate.
2. If a pod needs to talk to another pod, it can do so if it knows the IP address and the exposed port(s) of that pod.
3. Pods tend to be transient. So depending on their IP address for communicating can make the whole communication process very brittle/unreliable. To solve this, one can create services which will act as an abstraction for the pods. The service will have a single DNS name and it’ll load balance the requests among the pods.

But how exactly how would such an app with multiple pods talking to each other would look like? Let’s try out a simple app that demonstrates the 3rd scenario described above since that’s the recommended approach to go. Let’s consider a simple app with a single endpoint /quote, which would simply return a quote.

Our app would consist of the following services:

• A quotes service – this would return a quote with various metadata associated with the quote (e.g., author, category, length etc.). To keep it simple, we’ll just call the https://quotes.rest/qod to get the quote and return it from the /quote endpoint of this service.
• A proxy service – this would sit in between the quotes API and the users and present the users with a simplified response with all the additional metadata etc. stripped from the payload.

For ease of implementation and clarity let’s use Ballerina to implement these 2 services. In addition to having network abstractions built in to the language, it also provides support for generating Docker and Kubernetes artifacts for our applications. But for the purpose of this exercise, we’ll just stick to generating the Docker images.