The life cycle of the container

One, the life cycle of the container

Two, composition introduction

2.1 Init container

Pod can have multiple containers, and applications run in the containers. But it may also have one or more Init containers that start before the application container

Init containers are very similar to ordinary containers, except for the following two points:

• Init container always runs until it completes successfully
• Each Init container must complete successfully before the next Init container starts

If the Pod's Init container fails, Kubernetes will continue to restart the Pod until the Init container succeeds. However, if the restartPolicy corresponding to the Pod is Never, it will not restart

Init container template

apiVersion:v1
kind:Pod
metadata:
  name:myapp-pod
  labels:
    app:myapp
spec:
  containers:
 - name:myapp-container
	images:busybox
	command:["sh", "-c", "echo The App is Running! && sleep 3600"]
  initContainers:
 - name:init-myservice
	image:busybox
	command:["sh", "-c","until nslookup myservice;do echo waiting for myservice;sleep 2;done; "]
 - name:init-mydb
    image:busybox
	command:["sh","-c", "until nslookup mydb;do echo waiting for mydb;sleep 2;done;"]

Special Note:

• During the Pod startup process, the Init container will start after the initialization of the network and data volume in order . Each container must exit successfully before the next container starts
• If it exits due to runtime or failure, the container will fail to start, and the Init container will retry according to the policy specified by the restartPolicy of the Pod
• Before all Init containers are unsuccessful, the Pod will not become Ready. The ports of the Init container will not be aggregated in the Service ( that is, the ports of multiple Init containers are the same and will not conflict, because the Init container will exit after running successfully, and then start the next Init container ). The Pod being initialized is in the Pending state, but the Initializing state should be set to true
• If the Pod restarts, all Init containers must be restarted
• Modifications to the Init container spec are restricted 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
• The Init container has all the fields of the application container, except readinessProbe. Because the Init container cannot define states other than readiness other than completion. This will be enforced in the verification (???)
• The name of each app and Init container in the Pod must be unique; sharing the same name with any other container will throw an error during verification

2.2 Container probe

The probe is a periodic diagnosis performed by the kubelet on the container. To perform diagnosis, kubelet calls the Handler implemented by the container.

There are three types of handlers:

• ExecAction: execute the specified command in the container, if the return code is 0 when the command exits, the diagnosis is considered successful
• TCPSocketAction: Perform TCP check on the container IP address on the specified port. If the port is open, the diagnosis is considered successful
• HTTPGetAction: Perform an HTTP Get request on the IP address of the container on the specified port and path. If the response status code is greater than or equal to 200 and less than 400, the diagnosis is considered successful

Each probe will get one of the following three results:

• Success: The container passed the diagnosis
• Failed: The container failed the diagnosis
• Unknown: The diagnosis failed, so no action will be taken

Detection method:

• livenessProbe: Indicates whether the container is running. If the survival detection fails, the kubelet will kill the container, and the container will be affected by its restart strategy. If the container does not provide a survival probe, the default status is Success
• readinessProbe: Indicates whether the container is ready to service the request. If the ready detection fails, the endpoint controller will delete the IP address of the Pod from all Service endpoints that match the Pod. The ready state before the initial delay defaults to Failure. If the container does not provide the ready probe, the default status is Success

Example 1: Ready probe

apiVersion:v1
kind:Pod
metadata:
  name:readiness-httpget-pod
  namespace:default
spec:
  containers:
  - name:readiness-httpget-container
    image:XXX/myapp:v1
    imagePullPolicy:IfNotPresentports
    readinessProbe:
      httpGet:
        port:http
        path:/index1.html
      initialDelaySeconds:1
      periodSceonds:3

Example 2: Survival detection

apiVersion:v1
kind:Pod
metadata:
  name:liveness-exec-pod
  namespace:default
spec:
  containers:
 - name:liveness-exec-container
    image:hub.atguigu.com/library/busybox
    imagePullPolicy:IfNotPresentports
    command:["/bin/sh","-c","touch /tmp/live;sleep 60;rm -rf /tmp/live;sleep 3600"]
    livenessProbe:
      exec:
        command:["test","-e", "/tmp/live"]
      initialDelaySeconds:1
      periodSceonds:3

2.3 Pod phase (termination) possible values

• Pending: Pod has been accepted by the Kubernetes system, but one or more container images have not been created yet. The waiting time includes the time to schedule the Pod and the time to download the mirror through the network, which may take some time
• Running: The Pod has been bound to a node, and all containers in the Pod have been created. At least one container is running, or is being started or restarted
• Succeeded: All containers in the Pod have been successfully terminated and will not restart
• Failed: All containers in the Pod have been terminated, and at least one container was terminated due to failure. In other words, the container exits with a non-zero status or is terminated by the system
• Unknown: The status of the Pod cannot be obtained for some reasons, usually because the communication with the host where the Pod is located fails

2.4 Pod classification

• Autonomous Pod: Pod has exited, this type of Pod will not be created
• Pod managed by the controller: In the life cycle of the controller, the number of copies of the Pod must always be maintained