What is a Kubernetes Sidecar Container?

One of the most useful patterns in Kubernetes is the Sidecar pattern. But what is a sidecar pattern?

Typically a Pod in Kubernetes contains one container only(single container pod). But it is possible for a Pod to contain more than one container. In that case, it is called a multi-container pod

When another container is added to a pod to provide extra functionality to the main container, but without requiring changing the main container, it is called a sidecar container.

One or more containers that share the same pod share at least two things:

  • A file system — this means that you can share files between two or more containers in the same pod using shared volumes. Shared volumes are simply shared folders.
  • Networking — communication between containers in the same Pod can take place via the loopback interface — localhost

There are many different applications of the Sidecar pattern in Kubernetes. I will just mention a couple of use-cases, and then I will tell you about how I have used the sidecar pattern to my advantage.

Examples of Sidecar Containers in Kubernetes

A common use-case for the Sidecar pattern is to add an additional container for proxying requests between Pods, for instance, to encrypt Pod to Pod communication via Service Mesh, or as a database proxy(See example from Google Cloud —  https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk).

How I have used the Sidecar Pattern in Kubernetes

My practical application of the Sidecar pattern was to add a simple file synchronization utility between Pods to enable me to scale WordPress without having to rely on mounting shared network storage directly on the pods. There are many considerations for not to do this, such as performance, resiliency, and costs. But I won’t dwell on that topic in this article.

I implemented the sidecar pattern by sharing the wp-content folder in WordPress with a File Sync container. The FileSync container job is to upload any new files added to WordPress to a GCS Cloud bucket and to make sure that each Pod running WordPress contains a copy of the files inside wp-content whenever a new media item is added to the GCS Cloud Bucket. 
All of this logic is implemented in the FileSync container that runs alongside the WordPress container. There is only minimal YAML configuration needed

To enable file sharing between two containers inside the same pod, we just need to add three pieces of YAML:

  1. Add a volume declaration to the pod:
 spec:
   volumes:
     - name: wpcontent
       emptyDir: { }

2. Add a volume mount to the wordpress container:

containers:
- name: wordpress
  ...  
  volumeMounts:
  - name: wpcontent
    mountPath: /var/www/html/wp-content

3. Add a volume mount to the file sync container:

containers:
   name: fileSync
   volumeMounts:
     - name: wpcontent
       mountPath: /data/wpcontent

And with that, both containers can share files via local storage. One really important aspect of this type of shared volume is that any data in the folder is lost after a Pod is recreated.

In my use case that’s not much of an issue, because as soon as the file is written to the local storage, it gets uploaded to a GCS bucket.

All the work to do the synchronization with GCS was done via gsutil rsync via a simple bash script in the fileSync container.
The beautiful thing about this solution is that if I have any future requirements on this type of file synchronization with GCS, I can re-use this sidecar container.

Resources

Example of sidecar container for CloudSQL 
https://kubernetes.io/docs/concepts/storage/persistent-volumes/

Kubernetes Documentation
https://kubernetes.io/docs/concepts/workloads/pods/#workload-resources-for-managing-pods