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.
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.
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.