Multi-Container Pod Design Patterns in Kubernetes — Sidecar Pattern

Kubernetes is an open-source major player container orchestration engine for automating deployments, scaling and management of containerized applications.

A pod is the basic building block of the kubernetes application. Pods encapsulate containers. A pod may have one or more containers, storage, IP Addresses and some other options that govern how containers should run inside the pod.

A pod that has one container is called a single-container pod. It’s the most common kubernetes use case. A pod that has multiple co-related containers is called a multi-container pod. You don’t always need multi-container pods. When do you need to use them is the question. Some of the cases where you may need to use them are:

When the containers have the exact lifecycle or when the containers must run on the same node. A scenario where you have a helper process that needs to be located and managed on the same node as the primary container.
For simpler communication between containers in the pod. These containers can communicate through shared volumes (writing to a shared file or directory) and through inter-process communication (semaphores or shared memory) When the containers have the exact same lifecycle, or when the containers must run on the same node. The most common scenario is that you have a helper process that needs to be located and managed on the same node as the primary container.
There are three common design patterns and use cases for combining multiple containers into a single pod:

• Sidecar pattern (This article)
• Adapter pattern
• Ambassador pattern
• Sidecar Pattern

This pattern consists of a main application i.e. a web application plus a helper container with a responsibility that is essential to the web application but it’s not necessarily part of the application itself. The common sidecar containers are logging utilities, sync services, watchers, and monitoring agents. It does not make sense if a logging container is running while the application itself isn’t running, so we create a multi-container pod that has the main application and the sidecar container (logging container in this case).

Example
Let's deploy a simple pod to understand this pattern. A pod that has primary and sidecar containers.

The main container is a simple Nginx application serving on port 80 that takes the index.html from the volume mount location. The Sidecar container uses a busybox image and writes the current date to a log file every five seconds. In practice, your sidecar is likely to be a log collection container that uploads to external storage.

For you to apply this example, you need to install Minikube as a prerequisite Apply the manifest

You can clone this repo:

GitHub

Apply the pod manifest.

kubectl apply -f sidecar-pod.yaml

Once the pod is running, connect to the sidecar pod:

kubectl exec -it  sidecar-container-example -c main-container -- /bin/sh

Install curl on the sidecar

apt-get update && apt-get install -y curl

Access the log file(index.html) via the sidecar

curl localhost

Originally published by me on Medium

In the next article we will be talking about Adapter pattern. Until next time, thank you.

That’s all for now. Thanks for reading. Let’s connect on Twitter and LinkedIn 😁.