Getting Started with Communication

The problem

Pods are the smallest unit in Kubernetes and have a relatively short life span. They are born, and destroyed. They are never healed. The system heals itself by creating new Pods (cells) and by terminating those that are unhealthy or those that are surplus. The system can last long while Pods cannot.

Controllers, together with other components like the scheduler, ensure that the Pods are doing the right thing. They control the scheduler. We have used only one of them so far.

ReplicaSet are supposed to ensure that the desired number of Pods are always running. If there are too few Pods, ReplicaSet will create new ones. If there are too many of them, some will be destroyed. Pods that become unhealthy are terminated as well. All that, and a bit more, is controlled by ReplicaSet.

The problem with our current setup is that there are no communication paths. Our Pods cannot communicate with each other. So far, only containers inside a Pod can talk with each other through localhost. This necessitates both the API and the database needed to be inside the same Pod. This was a less than appropriate solution for quite a few reasons.

The main problem is that we cannot scale one without the other. We can not design the setup in a way that there are, for example, three replicas of the API and one replica of the database. The primary obstacle, again, is communication.

Truth be told, each Pod does get its own address. We could also split the API and the database into different Pods and configure the API Pods to communicate with the database through the address of the Pod it lives in.

However, because Pods are unreliable, short-lived, and volatile, we cannot assume that the database would always be accessible through the IP of a Pod. When that Pod gets destroyed (or fails), the ReplicaSet would create a new one and assign it a new address.

We need a stable, never-to-be-changed address that will forward requests to whichever Pod is currently running.

The solution

Kubernetes Services provide addresses through which associated Pods can be accessed.