Kubernetes: Sidecar container

What is a sidecar container

A sidecar container is a container that runs along with the main application container in a pod. Just like init container, sidecar container shares the storage and network with the application container. A sidecar container provides additional functionality to the application container without a need to update or change the application code. This means that the peripheral tasks such as logging or auditing can be implemented as a separate component in the sidecar.

Unlike init container, a sidecar container has the same lifecycle as that of the parent application as it is being created and destroyed alongside the application container.

Advantages and use cases of sidecar container

• A sidecar container can monitor system resources used by both the sidecar and the primary application as it shares the storage and network services with the primary application.
• Service Mesh for observability, security and traffic management is usually achieved by implementing these tools as a sidecar.
• As sidecar runs alongside the primary application container, there is no significant latency between communication.

Creating a sidecar container

In this article we will create a pod which contains a primary application container and a sidecar container. The main application will host a web server whereas the sidecar container will extract the logs and ships it to a log aggregator.

Use the below files to create a pod with two containers i.e., an application container & a sidecar container and a service of type NodePort. When the below manifest file is applied to the Kubernetes cluster, the emptyDir volume defined in the manifest file is created first and both the containers can read and write files from and to the volume. As a result when the Pod is created, logs generated by nginx container in the directory /var/log/nginx can be accessed by the sidecar container.

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  containers:
    - name: main-application
      image: nginx
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx
    - name: sidecar-container
      image: busybox
      command: ["sh","-c","while true; do cat /var/log/nginx/access.log; sleep 30; done"]
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx
  volumes:
    - name: shared-logs
      emptyDir: {}

apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  type: NodePort
  ports:
    - targetPort: 80
      port: 80
      nodePort: 30080
  selector:
    app: webapp

Apply the pod and service manifest file to create the resources. In the logs below we can see that sidecar container was able to stream the logs of nginx webserver on the terminal which can then be collected by tools like fluentd or logstash.

# kubectl create -f pod.yaml 
pod/webapp created

# kubectl apply -f service.yaml 
service/webapp-service created

# kubectl logs -f webapp -c sidecar-container
10.42.0.1 - - [03/Jan/2023:21:26:01 +0000] "GET / HTTP/1.1" 200 615 "https://e146a76047354eb8.labs.kodekloud.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36" "89.246.102.40, 34.120.45.220, 169.254.1.1, 10.255.119.81"
10.42.0.1 - - [03/Jan/2023:21:26:01 +0000] "GET / HTTP/1.1" 200 615 "https://e146a76047354eb8.labs.kodekloud.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36" "89.246.102.40, 34.120.45.220, 169.254.1.1, 10.255.119.81"
10.42.0.1 - - [03/Jan/2023:21:26:01 +0000] "GET / HTTP/1.1" 200 615 "https://e146a76047354eb8.labs.kodekloud.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) 

Considerations for resource limit and usage of sidecar.

• As sidecar are configured to enhance or extend the existing functionality of the primary application container, hence the resource limits for sidecar container should not exceed the resource limit as that of the primary application container.
• The total resource utilization of a pod is the sum total of the primary application container and sidecar container resource usage. Hence if the resource utilization of sidecar container is too much it can cause pod eviction due to OOM(out of memory) in case of node pressure eviction.

Final thoughts

Sidecar are useful in extending and enhancing the existing functionalities of the primary application. Health of sidecar container is as important as that of the primary application container. Hence, remember to create health check probes for sidecar container as well.