Sidecar Container vs Init Container in Kubernetes

Table of contents

Reading Time: 4 minutes

Introduction

Init containers are special containers that run before main containers run in a pod. Init containers support many of the features of application containers. Sidecar containers are containers that run along with the main container in a pod. You can define any number of sidecar containers to run alongside the main container

What is Sidecar Container?

A sidecar is just a container that runs on the same Pod as the application container. It shares the same volume and network as the main container, it can “help” or enhance how the application operates.

A Sidecar container is a second container to add the pod. Why sidecar container added to the pod or main container? because it needs to use the same resources that use by the main container.

we have a webserver container running the Nginx image. The logs produced by the main container are not enough to be placed on a persistent volume. However, developers need access to the last 24 hours of logs so they can trace issues and bugs. Therefore, we need to ship the access and error logs for the webserver to a log-aggregation service. Following the separation of concerns principle, we implement the Sidecar pattern by deploying a second container that ships the error and access logs from Nginx. Nginx does one thing, and it does it well; serving web pages. The second container also specializes in its task; shipping logs. Since containers are running on the same Pod, we can use a shared empty Dir volume to read and write logs.

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

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

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

The above definition is a standard Kubernetes Pod definition except that it deploys two containers to the same Pod. The sidecar container conventionally comes second in the definition so that when you issue the kubectl execute the command, you target the main container by default.

Use case of side-car container

It used by log shippers, log watchers, monitoring agents

The main container is an Nginx container that stores its logs on a volume mounted on /var/log/nginx. Mounting a volume at that location prevents Nginx from outputting its log data to the standard output and forces it to write them to access.log and error.log files.

What is Init Container?

A pod can have Init Containers in addition to application containers. Init containers allow you to reorganize setup scripts and binding code.

An init container is the one that starts and executes before other containers in the same Pod. It’s meant to perform initialization logic for the main application hosted on the Pod.

Properties of Init container

It contains utilities or setup scripts not present in an app image ( making images light-weight)
They always run to completion
Init container executes sequentially and each of the init containers must succeed before the next can run.
They support all the fields and features of app containers, including resource limits, volumes, and security settings.
Init-containers do not support lifecycle, liveness probe, readiness probe, or startup probe because they must run to completion.

Use cases of Init container

Init containers can contain utilities or custom code for the setup that are not present in an app image.
They can be given access to Secrets that app containers cannot access.
Clone a Git repository into a Volume
It can be used to wait for a service to start that is to be used by the main app
An init container is a good candidate for delaying the application initialization until one or more dependencies are available.

Create a pod with init-container

apiVersion: v1
kind: Pod
metadata:
  name: init-container
  labels:
    purpose: initContainers-demo
spec:
  initContainers:
  - name: init-container
    image: busybox
    command: ["echo","I am init-conatiner"]
  - name: init-busybox2
    image: busybox
    command: ["sleep","30"]

  containers:
  - name: main-container
    image: busybox
    command: ["echo","main container"]
  restartPolicy: Never

output of init-container

kubectl apply -f init-demo.yml
pod/init-pod created
// Status of init-pod
kubectl get pod init-container -o wide
NAME             READY   STATUS      RESTARTS   AGE   IP            NODE       
init-container   0/1     Completed   0          51s   172.17.0.30   minikube   
kubectl get po init-container
NAME             READY   STATUS      RESTARTS   AGE
init-container   0/1     Completed   0          4m19s

Conclusion

Sidecar vs init container if you find that the sidecar container logic is getting more complex or becoming more tightly coupled with the main application container, it may better be integrated with the main application’s code. Sidecar vs init container Each Init container must complete successfully before the next one starts.