Kubernetes init container

[TOC]

Brief introduction

In many scenarios, the following initialization is required before the application starts:

• Wait for other associated components to run correctly (for example, a database or a background service)
• Generate a configuration file based on an environment variable or a configuration template
• Get the local desired configuration from the remote database, or register itself in a central database
• Download the dependent packages or perform some pre-configuration actions on the system

Kubernetes v1.3 introduced some new features of the alpha version of Init container (which was updated to beta in the v1.5 version) to start one or more "initialize" containers before launching the application container, completing the pre-conditions required for the application container. The Init container is essentially the same as the application container, but it is a task that ends only once, and must be completed before the system can continue execution of the next container. Depending on the pod restart policy, when init container fails to execute, the pod will automatically start failing when Restartpolicy=never is set, and the pod will be automatically restarted by the system when the Restartpolicy=always is set.

Configuration

The following is an example of a Nginx application, before starting Nginx, by initializing the container busybox to create a index.html home file for Nginx. A shared volume is set up for init container and Nginx for Nginx to access the index.html files set by the Init container:

Nginx-init-containers.yaml content is as follows:

apiVersion: v1kind: Podmetadata:  name: nginx  annotations:spec:  initContainers:  - name: install    image: busybox    command:    - wget    - "-O"    - "/work-dir/index.html"    - "http://kubernetes.io"    volumeMounts:    - name: workdir      mountPath: "/work-dir"  containers:  - name: workdir    image: nginx    ports:    - containerPort: 80    volumeMounts:    - name: workdir      mountPath: /usr/share/nginx/html  dnsPolicy: Default    volumes:    - name: workdir      emptyDir: {}

The difference between the Init container and the application container

A simple explanation of the difference between the two:

• Init container run in a different way than the application container, they must be done before the application container, and when multiple init container are set, they are run sequentially, and only the previous Init container runs successfully before an init Container After all init container have run successfully, kubernetes initializes the various information for the pod and begins to create and run the application container.
• In the definition of init container, you can also set resource limits, volume usage and security policies, and so on. However, the settings for resource restrictions differ from the application container:
  • If more than one INIT container defines a resource request/resource limit, the maximum value is taken as the resource request value/resource limit value for all init container.
  • The effective resource request value/resource limit value for Pod takes the following larger values:
    • Sum of Resource request value/limit values for all application containers
    • Valid resource request value/limit value for init container
  • The scheduling algorithm calculates based on the pod's valid resource request value/limit value, which means that Init container can reserve system resources for initialization, even if subsequent application containers do not need to use those resources.
  • The effective QoS level for Pods applies to init container and application containers.
  • Resource quotas and restrictions will be consistent with the scheduling mechanism based on the effective resource request/restriction of the pod.
• Init container cannot set readinessprobe probes because they must run successfully before they can continue to run normal containers defined in the pod. When the pod restarts, the Init container will rerun, and the common pod restart scenario is as follows:
  • When the image of Init container is updated, the Init container will rerun, causing the pod to restart, only updating the application container's image will only cause the application container to be restarted.
  • When the pod's infrastructure container is updated, the pod restarts.
  • or all application containers in the pod are terminated, and restartpolicy=always, the pod restarts.

Kubernetes init container