Init Container

Posted on | Edited on | In

Kubernetes version 1.13.2

In ICP4D non-root development, I see in each tier the pod contains init container, for example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
...
    hostname: is-xmetadocker
    hostIPC: true
    initContainers:
    - name: load-data
      image: "mycluster.icp:8500/zen/is-db2xmeta-image:11.7.1-1.0"
      imagePullPolicy: IfNotPresent
      securityContext:
        capabilities:
         add: ["SETFCAP", "SYS_NICE", "IPC_OWNER"]
      command: ['/bin/bash', '-c', '--']
      args: [ " set -x;
              ...
              "
             ]
      env:
      - name: DEDICATED_REPOS_VOLPATH
        value: /mnt/dedicated_vol/Repository
      volumeMounts:
      - name: xmeta-pv-volume
        mountPath: "/mnt/dedicated_vol/Repository"
...

Understanding

What is this and what is it for? Let’s take a look. First reference to official documentation.

Init Containers, which are specialized Containers that run before app Containers and can contain utilities or setup scripts not present in an app image.

A Pod can have multiple Containers running apps within it, but it can also have one or more Init Containers, which are run before the app Containers are started.

Init Containers are exactly like regular Containers, except:

  • They always run to completion.
  • Each one must complete successfully before the next one is started.

If an Init Container fails for a Pod, Kubernetes restarts the Pod repeatedly until the Init Container succeeds. However, if the Pod has a restartPolicy of Never, it is not restarted.

Differences from Regular Containers

Init Containers support all the fields and features of app Containers, including resource limits, volumes, and security settings. However, the resource requests and limits for an Init Container are handled slightly differently.

Init Containers do not support readiness probes because they must run to completion before the Pod can be ready.

Usage

Init Containers have separate images from app Containers (actually they can have the same), they have some advantages for start-up related code:

  • They can contain and run utilities that are not desirable to include in the app Container image for security reasons.
  • They can contain utilities or custom code for setup that is not present in an app image. For example, there is no need to make an image FROM another image just to use a tool like sed, awk, python, or dig during setup.
  • The application image builder and deployer roles can work independently without the need to jointly build a single app image.
  • They use Linux namespaces so that they have different filesystem views from app Containers. Consequently, they can be given access to Secrets that app Containers are not able to access.
  • They run to completion before any app Containers start, whereas app Containers run in parallel, so Init Containers provide an easy way to block or delay the startup of app Containers until some set of preconditions are met.

You can check the logs of init container:

1
kubectl logs <pod name> -c <init container> -n test-1

During the startup of a Pod, the Init Containers are started in order, after the network and volumes are initialized. Each Container must exit successfully before the next is started.

If the Pod is restarted, all Init Containers must execute again. Init Container code should be idempotent.

0%