k8s: Initialize the container

Initialize the container

Init Container is the container used for initialization. It can be one or more. If there are more than one, these containers will be executed in the order defined. Only after all the Init Containers are executed, the main container will be started. All containers in a Pod share data volumes and network namespaces, so the data generated in the Init Container can be used by the main container.

Init Container is somewhat similar to the previous hook function, but it does some work before the container is executed. From an intuitive point of view, the initialization container is indeed a bit like PreStart, but the hook function and our InitContainer are in different stages. We can understand it through the following figure:

From the above picture, we can intuitively see that PostStart and PreStop, including liveness and readiness, belong to the life cycle of the main container, while the Init Container is independent of the main container. Of course, they all belong to the life cycle of the Pod.

In addition, we can see that there is an infra container on the right side of our pod above. We can check the running Docker container corresponding to any pod in the cluster environment. We can find that each pod contains a pause-amd64 image. This is our infra image. We know that all containers under the pod share the same network namespace.

很多 Pod 启动不起来就是因为这个 infra 镜像没有被拉下来，所以需要提前拉取到节点上面。

The difference between an init container and a normal container:

1. Init containers always run until successful.
2. Each Init container must complete successfully before the next Init container can start.

If the Pod's Init container fails, Kubenetes will continuously restart the Pod until the Init container succeeds. However, if the Pod's corresponding restartPolicy is Never, it will not be restarted.

Advantages of Init Containers:

1. It can contain and run utilities. For security reasons, it is not recommended to include these utilities in the application container image.
2. They can contain tools and custom code to install, but cannot appear in the application container image. For example: it is not necessary to FROM another image to create a mirror, only to use tools like sed, awk, python or dig during the installation process.
3. Application container images can separate out the roles of creation and deployment without necessarily combining them to build a single image.
4. Init containers use LinuxNamespaces, so have a different view of the file system than application containers. Therefore, the Init container can have Secret permissions, but the application container cannot.
5. They must run to completion before the application container starts, and application containers run in parallel, so Init containers provide an easy way to block or delay the start of the application container until the prerequisites are met.

Init container application scenarios:

1. Waiting for other modules to be ready: It can be used to solve the dependency problem between services. For example, we have a web service that depends on another database service, but when we start this web service, we cannot guarantee that the dependent database service has been started, so there may be exceptions when the web service connects to the database within a period of time. To solve this problem, we can use a nitContainer in the Pod of the web service to check whether the database is ready in the initialization container. After the initialization container is ready, the initialization container will exit, and then our main container web service will be started. There will be no problem connecting to the database at this time.
2. Do initial configuration: For example, detect all existing member nodes in the cluster, and prepare cluster configuration information for the main container, so that the main container can use this configuration information to join the cluster after it starts up.
3. Other scenarios: such as registering pods to a central database, configuration center, etc.

example

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
  labels:
    demo: init-demo
spec:
  containers:
  - name: init-demo
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-demo1
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice;sleep 2; done;']
  - name: init-demo2
    image: busybox
    command: ['sh', '-c', 'until nslookup mysql; do echo waiting for mysql; sleep 2;done;']
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - port: 1234
    targetPort: 4567
    protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 4321
    targetPort: 7654
    protocol: TCP
[root@master ~]# kubectl  get pods
NAME                                      READY   STATUS      RESTARTS   AGE
init-demo                                 0/1     Init:0/2    0          6s

[root@master ~]# kubectl get pods
NAME                                      READY   STATUS      RESTARTS   AGE
init-demo                                 1/1     Running     0          4m24s

[root@master ~]# kubectl get service
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        13d
myservice    ClusterIP   10.108.202.229   <none>        1234/TCP       4m40s
mysql        ClusterIP   10.110.222.227   <none>        4321/TCP       4m39s

[root@master ~]# kubectl  logs init-demo
the app is running1

Container Special Instructions

1. During Pod startup, Init containers are started sequentially after network and data volume initialization. Each container must exit successfully before the next container can start
2. If the container fails to start due to runtime or failure exit, it will retry according to the policy specified by PodrestartPolicy. However, if the Pod's restartPolicy is set to Always, the RestartPolicy policy will be used when the Init container fails.
3. The Pod will not become Ready until all Init containers have failed. The port of the Init container will not be aggregated in the Service. The Pod that is being initialized is in the Pending state, but the Initializing state should be set to true
4. If the Pod restarts, all Init containers must be re-executed
5. Modifications to the Init container spec are limited to the container image field, and modifications to other fields will not take effect. Changing the Image field of the Init container is equivalent to restarting the Pod.
6. Init container has all fields of application container. In addition to readinessProbe, because the Init container cannot define other states than readiness other than completion. This is enforced during validation.
7. Each app and init container name in a Pod must be unique; sharing the same name with any other container will throw an error during validation.