Kubernetes Init Containers Quickstart Guide

In Kubernetes, a pod can host one or more containers of an instance of an application. They can also host one or more Init containers. Use this Quickstart guide to learn more about Kubernetes Init containers.

What Are Init Containers

Init containers are a special type of container that run before the application containers. They must run and exit successfully for the main application containers to run.

Characteristics of Init Containers

Init containers are different from application containers in a way that makes them suitable for initialization purposes. Few points about init containers:

1. If the pod has many init containers, each init container is run after the completion of the previous one.
2. The restart policy defines the behavior of kubelet in case an init container fails. If the restart policy is set to Always, the kubelet restarts the container until it runs and exits successfully (exit code 0). If the restart policy is set as Never, kubelet does not attempt to restart the init container and the pod fails.
3. In case the pod is restarted, if your init container writes files on EmptyDir, then it should be prepared for the existence of data created in the previous pod lifecycle.
4. The following fields are not applicable to init containers:
   • lifecycle
   • livenessProbe
   • readinessProbe
   • startupProbe
5. Init containers are separate entities from application containers. They use different images, and they are configured differently. This makes the pod modular and easy to manage.

Uses of Init Containers

Init containers can serve multiple purposes. They are used for application initialization purposes. The following are some use cases:

1. They can be used to store sensitive credentials and access the required data. In case a pod gets compromised, the application container cannot expose those sensitive credentials. This increases security.
2. They can delay the pod creation until a set of preconditions are met. These preconditions can be:
   • Fetching data for the application containers.
   • Registering the application with a remote server
   • Waiting for some service or resource to be ready.
3. They can generate configuration files using variable data like External IP addresses, pod IP, and so on.

Using Init Containers

Init containers are defined in the pods.spec.initContainers field. To follow along with this guide, use the following configuration file to create an Nginx deployment with an init container. The init container creates a web page for Nginx and delays the container exit by 20 seconds.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-server
  name: nginx-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-server
  template:
    metadata:
      labels:
        app: nginx-server

    spec:

      volumes:
      - name: common-disk
        emptyDir: {}

      initContainers:
      - name: busybox
        image: busybox
        volumeMounts:
        - name: common-disk
          mountPath: /web-files
        command: ["/bin/sh"]
        args: ["-c", "echo '<h2>Init container added this line here</h2>' > /web-files/index.html && sleep 20"]

      containers:
      - image: nginx
        name: nginx
        volumeMounts:
        - name: common-disk
          mountPath: /usr/share/nginx/html

To create the deployment, use:

$ kubectl apply -f myApp.yaml

Expected output:

deployment.apps/nginx-deploy created

To check the status of the deployment, use:

$ kubectl get deployment

Sample output:

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   0/1     1            0           7s

As you can see under the READY field, a 0/1 replica is available. This is because the init container is not finished. Now check the status of the pod:

$ kubectl get pod

Sample output:

NAME                            READY   STATUS     RESTARTS   AGE
nginx-deploy-5c77b8f897-94r6w   0/1     Init:0/1   0          26s

You can see that the pod is not ready. It is waiting for the init container to finish. The configuration file had the sleep 20 command at last, which is delaying the termination of the init container by 20 seconds. After the init container finishes, the status changes to:

NAME                            READY   STATUS            RESTARTS   AGE
nginx-deploy-5c77b8f897-94r6w   0/1     PodInitializing   0          33s

After the pod initializes, the status changes to:

NAME                            READY   STATUS    RESTARTS   AGE
nginx-deploy-5c77b8f897-94r6w   1/1     Running   0          51s

And the deployment status changes to:

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   1/1     1            1           91s

Conclusion

By now, you should have learned about init containers and how they work. You can now use them in designing your Kubernetes clusters and take advantage of what they have to offer.