1, Life cycle of Pod

The Pod follows a predefined life cycle, starting from the Pending phase. If at least one of the main containers starts normally, it enters the Running phase. Then it depends on whether any container in the Pod ends in the Failed state and enters the Succeeded or Failed phase.

During Pod operation, Kubernetes can restart the container to deal with some failure scenarios. Inside the Pod, Kubernetes tracks the status of different containers and determines the actions needed to make the Pod healthy again.

When running a Pod, you can view the running status of the Pod through the following commands:

kubectl get pod

The output results are as follows. The status field is the status of Pod.

[root@kubernetes-master01 ~]# kubectl get pod
NAME        READY   STATUS    RESTARTS   AGE
pod-nginx   1/1     Running   3          86m

The Status field in the above output result is a PodStatus object, which contains a phase field. The following is the definition of the value and value of the phase field:

Value	describe
Pending	Pod has been accepted by Kubernetes system, but one or more containers have not been created or run. This stage includes the time to wait for the pod to be scheduled and the time to download the image through the network.
Running	The Pod has been bound to a node, and all containers in the Pod have been created. At least one container is still running or is in a startup or restart state.
Succeeded	All containers in the Pod have been successfully terminated and will not be restarted.
Failed	All containers in the Pod have been terminated, and at least one container has been terminated due to failure. That is, the container exits in a non-zero state or is terminated by the system.
Unknown	The status of Pod cannot be obtained for some reason. This is usually because the communication with the host where the Pod is located fails.

Pod is the encapsulation of one or more containers. What are the status of the containers? There are three states of containers:

• Waiting: if the container is not in one of the Running or Terminated States, it is in the waiting state. The container in waiting state is still Running, and it completes the operations required for startup: for example, pull the container image from a container image warehouse, or apply Secret data to the container. When you use kubectl to query the Pod of the container with waiting status, you will also see a Reason field, which gives the Reason why the container is waiting.
• Running: the running status indicates that the container is running and no problem has occurred. If the postStart callback is configured, the callback has been executed and completed. If you use kubectl to query the Pod of the container containing running status, you will also see information about the container entering running status.
• Terminated: the container in the terminated state has started execution and either ended normally or failed for some reason. If you use kubectl to query the Pod of the container with the terminated status, you will see the reason why the container enters this status, the exit code and the start and end time during the execution of the container. If the container is configured with a preStop callback, the callback will be executed before the container enters the terminated state.

According to the running state of the container, the container will resume the container according to the restart strategy. The default values of Always restart policy and Never restart policy are specified in the container.

• Always: when the container fails, Kubernetes will automatically restart the container.
• OnFailure: when the container terminates and the exit code is not 0, Kubernetes will automatically restart the container.
• Never: Kubernetes will not restart the container regardless of its running state.

Next, let's run the Pod of a busybox container and set postStart and preStop.

We edit a file pod nginx post pre Yaml, as follows:

apiVersion: v1
kind: Pod
metadata:
  name: pod-nginx-post-pre
spec:
   containers:
   - name: nginx
     image: nginx
     lifecycle:
       postStart:
         exec:
           command: ['sh','-c','touch /tmp/file; echo Pod postStart >> /tmp/file;']
       preStop:
         exec:
           command: ['sh','-c','echo Pod preStop >> /tmp/file;']

Pod pod nginx post pre runs an nginx container and sets two hook functions in it:

• postStart: after the container starts, create a file in the tmp directory and print Pod postStart to the file.
• preStop: before the container is about to close, print Pod preStop to the file file in the tmp directory.

Create this Pod:

[root@kubernetes-master01 k8s-yaml]# kubectl apply -f pod-nginx-post-pre.yaml
pod/pod-nginx-post-pre created

Log in to this Pod and view the contents in the file:

[root@kubernetes-master01 k8s-yaml]# kubectl exec -it pod-nginx-post-pre -- /bin/sh
# cat /tmp/file
Pod postStart

As required, there is content Pod postStart in / tmp/file.

For the demonstration of preStop, because the container executes the preStop function before closing, the logs and files in the container are gone after closing, so the demonstration effect is not good. Generally, the hook function preStop is used to clean up resources before the container is closed.

2, Configure liveness probe

Kubernetes uses the survival probe to know when to restart the container. For example, the survival probe can catch deadlocks (the application is running, but cannot continue with the next steps). Restarting the container in this case helps to make the application more available in case of problems.

Next, configure a pod busy live Yaml file, the contents of which are as follows:

apiVersion: v1
kind: Pod
metadata:
   name: pod-busy-live
spec:
   containers:
   - name: busybox
     image: busybox
     command: ['sh','-c','touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600;']
     livenessProbe:
       exec:
         command: ['cat /tmp/healthy;']
       initialDelaySeconds: 5
       periodSeconds: 5

The above file is the container of busybox. The commands are as follows: first create a file / TMP / health, delete / TMP / health after sleeping for 30 seconds, and then sleep for 600 seconds.

['sh','-c','touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600;']

livenessProbe is a survival probe. The functions of the configuration are as follows:

• command: ['cat / TMP / health;']: check whether there is a file / TMP / health.

• initialDelaySeconds: the waiting time before the first probe. In this example, it is 5 seconds.

• periodSeconds: except for the first detection, the interval of each detection is 5 seconds in this example.

Create this Pod:

[root@kubernetes-master01 k8s-yaml]# kubectl apply -f pod-busy-live.yaml
pod/pod-busy-live created

To view the status of this Pod:

[root@kubernetes-master01 k8s-yaml]# kubectl get pod
NAME            READY   STATUS    RESTARTS   AGE
pod-busy-live   1/1     Running   0          11s

Continuously check the status of the Pod. After 30 seconds, the RESTARTS field in the status of the Pod changes to 1, indicating that the Pod has been restarted.

[root@kubernetes-master01 k8s-yaml]# kubectl get pod
NAME            READY   STATUS    RESTARTS   AGE
pod-busy-live   1/1     Running   1          54s

Check the specific operation of Pod through the following instructions:

[root@kubernetes-master01 k8s-yaml]# kubectl describe pod pod-busy-live

At the bottom of the output result, the container is restarted because the liveness probe detection failed.

Events:
  Type     Reason     Age                  From                          Message
  ----     ------     ----                 ----                          -------
  Normal   Scheduled  <unknown>            default-scheduler             Successfully assigned default/pod-busy-live to kubernetes-worker01
  Normal   Pulled     15m (x3 over 17m)    kubelet, kubernetes-worker01  Successfully pulled image "busybox"
  Normal   Created    15m (x3 over 17m)    kubelet, kubernetes-worker01  Created container busybox
  Normal   Started    15m (x3 over 17m)    kubelet, kubernetes-worker01  Started container busybox
  Normal   Killing    14m (x3 over 16m)    kubelet, kubernetes-worker01  Container busybox failed liveness probe, will be restarted
  Normal   Pulling    14m (x4 over 17m)    kubelet, kubernetes-worker01  Pulling image "busybox"
  Warning  Unhealthy  12m (x16 over 17m)   kubelet, kubernetes-worker01  Liveness probe failed: OCI runtime exec failed: exec failed: container_linux.go:367: starting container process caused: exec: "cat /tmp/healthy;": stat cat /tmp/healthy;: no such file or directory: unknown

3, Configuring the readiness probe

Kubernetes uses the readiness probe to know when the container is ready and can begin to accept request traffic. For example, can a Java application be called to consumers normally? This can be used to detect the slow start container to make the container meet the status of external services before providing services. When all containers in a Pod are ready, the Pod can be regarded as ready. One purpose of this signal is to control which Pod is the back end of the Service. When the Pod is not ready, it will be removed from the load balancer of the Service.

An example of a ready probe is as follows. We a file pod nginx ready Yaml, as follows:

apiVersion: v1
kind: Pod
metadata:
   name: pod-nginx
spec:
   containers:
   - name: nginx
     image: nginx
     ports:
     - containerPort: 80
       hostPort: 80
     readinessProbe:
       httpGet:
         path: /
         port: 80

In this Pod, we run an nginx and start the readiness probe, which uses http check.

Create this Pod:

[root@kubernetes-master01 k8s-yaml]# kubectl apply -f pod-nginx-ready.yaml
pod/pod-nginx created

To view the running status of the Pod:

[root@kubernetes-master01 k8s-yaml]# kubectl get pod
NAME        READY   STATUS    RESTARTS   AGE
pod-nginx   0/1     Running   0          5s

Next, we log in to Pod and close nginx:

[root@kubernetes-master01 k8s-yaml]# kubectl exec -it pod-nginx -- sh
# nginx -s stop
2021/03/16 08:46:54 [notice] 34#34: signal process started
# command terminated with exit code 137

Now, let's check the running status of Pod and find that the RESTARTS is 1 and the container has been restarted once:

[root@kubernetes-master01 k8s-yaml]# kubectl get pod
NAME        READY   STATUS    RESTARTS   AGE
pod-nginx   1/1     Running   1          96s

The container probe is a periodic diagnosis performed by the Kubernetes container. To perform diagnostics, Kubernetes needs to call handlers implemented by the container. There are three types of handlers:

• ExecAction: executes 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 specified port on the IP address of the container. If the port is open, the diagnosis is considered successful.
• HTTPGetAction: execute HTTP Get request on the specified port and path on the IP address of the container. If the status code of the response 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.
• Failure: the container failed the diagnosis.
• Unknown: the diagnosis failed and no action will be taken.

For containers in operation, Kubernetes can choose whether to execute the following three probes and how to respond to the detection results:

• Indicates whether the probe container is running. If the live detection fails, kubelet will kill the container, and the container will decide the future according to its restart strategy. If the container does not provide a survival probe, the default state is Success.
• readiness Probe: indicates whether the container is ready to service the request. If the ready state detection fails, the endpoint controller will delete the IP address of the Pod from the endpoint list of all services matching the Pod. The status value of the ready state before the initial delay defaults to Failure. If the container does not provide a ready state probe, the default state is Success.
• startup Probe: indicates whether the application in the container has been started. If a start probe is provided, all other probes are disabled until the probe succeeds. If the startup Probe fails, Kubernetes will kill the container, and the container will restart according to its restart strategy. If the container does not provide a start probe, the default state is Success.

Guess you like it

If you are interested in the knowledge of containerization technology, you can read: Beautiful containerization technology Kubernetes column