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:
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 😁.
Top comments (1)
Heyo!
This is an awesome post! 🔥 In fact, the topic of your post would also work really well in The Ops Community too!
The Ops Community is a place for cloud engineers to share tips & tricks, tutorials, and career insights. Folks there commonly share information about DevOps and SecOps topics amongst other things.
Would you consider posting this article there too? Because The Ops Community is built on the same platform as DEV (Forem) you can fairly easily copy the Markdown and post your article there as well.
Really hope that you'll share your post with the community there and consider browsing the other Forem communities out there!