Use of Init-Container in Kubernetes

Table of contents

Reading Time: 3 minutes

This is the era of containerization and orchestration where the majority of the applications are following the trend of running on a container which is further deployed in a Kubernetes cluster. Init-container in Kubernetes is a special type of container that runs to completion before the main app’s container and the pod will repeatedly restart until all of them succeed.

Why init-Containers ?

It’s sometimes necessary to prepare the main container which will be running our application or the main logic and its accomplished through init containers.

There can also be situations where we need to execute particular utilities or setup scripts that are not present in our main image ( as it would make it heavy and we only need it once in the beginning ).

Some of its properties are :

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.

Let’s create a pod with init-container in Kubernetes

Here in this example, we have contains 2 init-container where the first container will simply print a message and the second one will sleep for 30 seconds after which our main container will come into action.

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

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

Now bring this pod up and you must get similar output

$ kubectl apply -f simple-pod.yml
pod/simple-pod1 created

//you can see the status of init-container
$ kubectl get pods
NAME          READY   STATUS     RESTARTS   AGE
simple-pod1   0/1     Init:0/1   0          27s

//and the pod comes to the the completion after a minimun of 30s (sleep time of second init-container)
$ kubectl get po
NAME          READY   STATUS      RESTARTS   AGE
simple-pod1   0/1     Completed   0          36s

How init-container come to Action in Kubernetes!

First, the kubelet will wait until the networking and storage are ready so that it can start running init containers.
It then runs the Pod’s init containers in the order they appear in the Pod’s spec.
Each init container must exit successfully before the next container starts.
A Pod cannot be in Ready state until all init containers have succeeded.
If the Pod Restarts, or is restarted, all init containers are executed again.

Note : Altering an init container image field is equivalent to restarting the Pod.

Few Use Cases of init-container

Init containers can contain utilities or custom code for 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 main app
An init container is a good candidate for delaying the application initialization until one or more dependencies are available.

Example

While setting up an Elasticsearch cluster we all have gone through the situation in which we need to set a few things before running the main container.

role: elastic-master
    spec:
      initContainers:
      - name: init-container1
        image: busybox
        command:
        - sysctl
        - -w
        - vm.max_map_count=262144
        securityContext:
          privileged: true
      - name: init-container2
        image: busybox:latest
        command:
        - sh
        - -c
        - chown -R 1000:1000 /usr/share/elasticsearch/data
        securityContext:
          privileged: true
        volumeMounts:
        - name: elastic-master-vol
          mountPath: /usr/share/elasticsearch/data
      
      containers:
      - name: elastic-master-container
        image: docker.elastic.co/elasticsearch/elasticsearch:7.7.0
        env:
        - name: node.name
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: cluster.name
          value: "elasticsearch-cluster"
        - name: node.master

In the above snippet of the yaml file, we are setting the value for vm.max_map_count and we are also changing the access permission for the mounted directory that the elasticsearch will use when it starts.

Lets sum-up !!!

Init-containers are special containers and Kubernetes will always execute them to completion before the main container(s) are executed. They can also be used in scenarios where you might want to wait for a service to be available, want to configure things at runtime, or init some data in a database.

Also, init-containers do not support lifecycle, liveness probe, readiness probe, or startup probe because they must run to completion.