Container-to-Container Communications in Kubernetes

What is container ?

A container image is a ready-to-run software package, containing everything needed to run an application: the code and any runtime it requires, application and system libraries, and default values for any essential settings.

What is Pod ?

Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.

A Pod (as in a pod of whales or pea pod) is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers. A Pod’s contents are always co-located and co-scheduled, and run in a shared context. A Pod models an application-specific “logical host”: it contains one or more application containers which are relatively tightly coupled. In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.

What is Kubernetes ?

Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

How do containers in the same Pod communicate?

Sometimes, you need to run more than one container in the same Pod.

They can do this using several different methods. In this article, we discuss two methods:

i- Shared Volumes and

ii- Inter-Process Communications

Shared Volumes

In Kubernetes, you can use a shared Kubernetes Volume as a simple and efficient way to share data between containers in a Pod. For most cases, it is sufficient to use a directory on the host that is shared with all containers within a Pod.

For example, we can create a Pod like so:

https://github.com/PalashGoel/shared-volume

Inter-Process Communications

Containers in a Pod share the same IPC namespace, which means they can also communicate with each other using standard inter-process communications ( POSIX-shared-memory and POSIX-message-queue). Containers use the strategy of the localhost hostname for communication within a pod.

1. POSIX- Shared-Memory

2. POSIX-Message-Queue

POSIX- Shared-Memory

POSIX stands for Portable Operating System Interface.

POSIX shared memory is a framework for inter-process communication (IPC) specified in the POSIX specifications. Two (or more) tasks can read from it and write to the shared memory zone while establishing the shared memory. POSIX shared memory does not always enforce copy disbursements, in contrast to other IPC structures (e.g., pipe, socket, etc.), and is desirable for certain programs.

For example, we can create a Pod like so:

https://github.com/PalashGoel/POSIX-shared-memory

POSIX-Message-Queue

Message queues allow processes to communicate by exchanging structured messages. As with pipes and FIFOs, processes can message queues follow a message passing IPC model for exchanging data in discrete messages.

For example, we can create a Pod like so:

https://github.com/PalashGoel/POSIX-message-queue

Closing Up

I hope this guide was helpful to you. I did this POC because I was curious about this, as there weren’t many resources available for POSIX in golang.