Hello, readers. This article talks about the concept of Kubernetes Init containers in detail.
So, let us begin!! 🙂
Understanding the concept of a Kubernetes Init Container
Kubernetes Init container is a specialized and customized container that runs before any application pod/container is up and running. It actually contains some customized setup scripts or utilities that one may not want to push to an application-specific image.
These init containers can be specified along with the other container specifications within the pod/deployment definition YAML file.
Every single pod can have multiple application containers running simultaneously. At the same time, it can have multiple init containers as well. These init containers run the commands and complete the execution before the app-specific containers start to run.
It is very important for the init containers to complete their execution successfully for the other app containers to start. Yes, the init containers always move towards a successful completion in an ideal scenario. In any case, if the pod’s init container fails, the kubelet tries to restart the init container until it becomes successful.
If the restart policy of a pod is set to Never and the init container fails, then the entire pod is a failure.
Having understood about init containers, let us now understand the difference between the usual containers and an init container.
Init Container versus Regular Container
A regular container has various fields such as liveliness probe, lifecycle, startup probe. etc. But an Init container does not support these fields as it has to run successfully for the regular containers to start.
Also, in case we specify multiple init containers, kubelet will run every init container in a sequence. Every previous init container has to complete its execution before the next one begins to run. Once all the init containers are successful, kubelet then spins up the application containers.
Advantages of an Init container
- As init containers run custom setup scripts and utilities, it is not necessary for us to build an image for the execution.
- Init containers can have access to application secrets which a regular container does not have access to.
- A successful execution of init containers is a mandatory condition for any app container to start. An init container has the power to withhold the execution of an app container until all the utilites has been executed successfully.
- Keeping too many of tools and software utilites in an app image can make it less secure and more prone to dangers. For the same, we can have those software utilites in the init container thus enhancing the security of the acutal application image.
Using Init Containers within a Kubernetes Deployment – Practical Implementation
Let us now have a look at the below example to understand the way to include init containers-
apiVersion: v1 kind: Pod metadata: name: demo-pod labels: app: myapp01 spec: containers: - name: app-container image: nginx initContainers: - name: init-utilities image: busybox:1.21 command: ['sh', '-c', "echo App has been initialized"]
Here, we have two containers being configured: a regular container to run some Nginx image and an init container. The init container is built upon the busybox image and it executes the commands.
By this, we have approached the end of this topic. Feel free to comment below, in case you come across any questions.
For more such posts related to Docker and Kubernetes, Stay tuned with us.
Till then, Happy Learning!! 🙂