Making Kubernetes Pods Talk to Each Other

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.

Continue reading
Advertisement

Creating a WSO2 Application Server cluster using AWS EC2 and Nginx as a load balancer

Introduction

The WSO2 Application server is used for hosting, deploying and managing applications, built on the WSO2 Carbon platform. A detailed documentation of the Application Server can be found here.

As is the case with other WSO2 products, multiple instances of the Application Server can be installed in a cluster. When in a cluster, the work is shared between the multiple instances although it appears as if though there is only a single instance of the Application Server (AS).

In this tutorial, we will be using AWS EC2 instances to create a AS cluster. The EC2 instances will be Ubuntu based. We’ll be creating a cluster of 3 AS nodes, using Nginx for load balancing and MySQL for storing the user management and registry data of the AS. More information on load balancing can be found here and here.

Continue reading