Continuing with our Kubernetes articles, in this new entry, we are going to see an example of the Sidecar Pattern on Kubernetes.

Kubernetes is an open-source container orchestrator that allows us to do continuous deployment, scaling, and container management, among other things. It is currently the de facto standard for all containerized applications.

Pod is smallest object on Kubernetes, representing a single instance of an application, as stated in this article. Additionally, a Pod is a collection of one or more containers and encapsulates a container of an application. So, based on this foundation and definition, let’s see how the Sidecar pattern works and what it is on Kubernetes.

What is the Sidecar Pattern on Kubernetes?

As previously stated, a Pod is a grouping of one or more containers, which implies that multiple containers can be hosted in the same Pod.

Now, if we start from the separation of concerns principle, each container has to do one and only one thing. So, what if we need a Pod to do more than one thing? We would need to apply the Sidecar pattern, for example.

In the Sidecar pattern on Kubernetes, we execute another container inside the Pod. So, when defining the pod or deployment, the new container will perform a new function.

Main characteristics of the Sidecar Pattern

• The Sidecar pattern enables the creation of modular containers that have various functionalities and can be reused in different parts with minimal modifications.
• A sidecar is a separate container within the same Pod, sharing network and volume with the main application.
• The most common uses where the sidecar is usually employed is in sending logs, log monitoring, and monitoring agents.
• Advantages of Sidecar pattern: separate container for a function means independent restarts and health checks. Additionally, we can use Kubernetes functionalities for containers.
• It is essential to keep in mind that the Sidecar’s objective is to be independent, as simple as possible, and able to be connected anywhere. So, if the sidecar consumes many resources or is too complex, we must consider merging it with the main application or not using this pattern.

Let’s see an example:

Example of Sidecar Pattern on Kubernetes

Imagine that we have a Pod that is running an nginx image. All the logs that our nginx generates need to be consulted by the monitoring team so they can detect any problems, so they must be sent to a volume. We have our nginx that functions as a web server, and following the principle of separation of concerns, it cannot take care of another task, so we need another container to send the logs to the specified volume.

This is when we apply the sidecar pattern; we are employing another container to perform a specific task within the same Pod.

We could define a Pod with a logs shipping sidecar for an nginx in the following way:

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-pattern
spec:
  volumes:
    - name: nginx-logs
      emptyDir: {}

  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: nginx-logs
          mountPath: /var/log/nginx

    - name: sidecar-container
      image: busybox
      command: ["sh","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 20; done"]
      volumeMounts:
        - name: nginx-logs
          mountPath: /var/log/nginx

In the definition of the previous Pod, we can see two different images within the same Pod. We see the main image, which is the web server in nginx, and the sidecar, which in this case is the famous busybox.

As we have previously mentioned, the idea in this example is to be able to view the nginx logs, which by default are access.log and error.log. We will mount a volume (which we’ll make ephemeral for the example) and dump the logs into it. Our sidecar will then query the logs every 20 seconds.

If we look at our sidecar, it meets the main characteristics that we have previously discussed. It’s an independent, simple container running in the same Pod, responsible for displaying and sending logs.

Conclusion

In this post, we have seen an example of the Sidecar Pattern on Kubernetes, to understand when and how to use it, which will help us add new functionalities to our Pods when needed.