Member-only story
Understanding Kubernetes Multi-Container Pod Patterns
A guide to Sidecar, Ambassador, and Adapter patterns with hands-on examples
A Kubernetes Pod is the basic building block of Kubernetes. Comprising of one or more containers, it is the smallest entity you can break Kubernetes architecture into.
When I was new to Kubernetes, I often wondered why they designed it so. I mean why containers did not become the basic build block instead. Well, a bit of doing things in the real environment and it makes more sense now.
So, Pods can contain multiple containers, for some excellent reasons — primarily, the fact that containers in a pod get scheduled in the same node in a multi-node cluster. This makes communication between them faster and more secure, and they can share volume mounts and filesystems with each other.
That helps us build on patterns we can implement to solve some particular problems. There are three widely recognised, multi-container pod patterns:
- Sidecar
- Ambassador
- Adapter
Let’s look at each of these with some hands-on examples.
Prerequisites
For the purpose of the hands-on exercise, you need to have a running Kubernetes cluster, and you need to clone this repo, and cd into it.
Sidecar
Sidecars derive their name from motorcycle sidecars. While your motorcycle can work fine without the sidecar, having one enhances or extends the functionality of your bike, by giving it an extra seat. Similarly, in Kubernetes, a sidecar pattern is used to enhance or extend the existing functionality of the container.
Your container works perfectly well without the sidecar, but with it, it can perform some extra functions. Some great examples are using a sidecar for monitoring and logging and adding an agent for these purposes.
For the demo, let’s look at a sidecar pattern with an application generating logs at a particular file path, where…
