Detailed description of Pod health check and service availability check in cloud native K8S

The Mid-Autumn Festival is full moon, rich and poor. Very comforting. -the war drama warlord "The Sword Comes"

Detection purpose: to maintain the robustness of pod. When the pod is suspended, the deployment will generate a new pod. However, if the pod is running normally, but there is a problem with the pod, the deployment cannot monitor it at this time. Therefore, it is necessary to detect whether POD provides services normally.

Kubernetes can check the health status of Pod through two types of probes: LivenessProbe and readiness probe, and Kubelet regularly executes these two types of probes to diagnose the health status of containers. It is achieved through deployment.

LivenessProbe and ReadinessProbe can be configured in the following three ways.

For each detection mode, you need to set parameters such as initialDelaySeconds and timeoutSeconds, and their meanings are as follows.

Kubernetes' ReadinessProbe mechanism may not be able to satisfy the judgment of some complex applications on the availability of services in the container.

The ReadinessGate of Pod is set in the readinessgate field of Pod definition. The following example sets a new ReadinessGate of type www.example.com/feature-1:.

Used to judge whether the container is alive (running state). If LivenessProbe detects that the container is unhealthy, kubelet will kill the container and make corresponding treatment according to the restart strategy of the container.

Execute a command inside the container. If the return code of the command is 0, the container is healthy.

Resource file definition

Run this deployment. When the pod is successfully created, create a new file and hibernate for 30 seconds, and delete the file when sleeping. Use activity to detect the existence of files.

After running for more than 30 seconds. The file has been deleted, so it is affected by the health check, and the pod restarts according to the restart policy.

This is the second time since 1999.

Check the container ID in the docker of the node machine. It's different before and after. Ensure that the POD is turned off and then restarted.

Call the HTTP Get method through the IP address, port number and path of the container. If the status code of the response is greater than or equal to 200 and less than 400, the container is considered healthy.

Create a resource file, that is, use related parameters.

Run deploy, and its probe mechanism accesses the default welcome page of Ngixn.

When deleting the welcome page, an access error will be reported, and the pod will be restarted after being clicked.

Perform TCP check through the IP address and port number of the container. If a TCP connection can be established, the container is healthy.

Resource file definition

Access port 8080, but port 8080 is not open, so the access will time out, the connection cannot be established, hit detection, and restart Pod.

Used to judge whether the container service is available (ready state), and the request can only be received when the Pod reaches the ready state. Responsible for not being able to visit

Resource file definition, using hooks to build files that need to be checked.

Use Ngixn to create three PODs, and create an SVC through PODs for testing.

Modify home page text

Modify label

Delete file detection

Creating SVC with POD

Test SVC is normal, and the three pods will be loaded normally.

Delete file test

You will find that the pod of pod-liveness is no longer available.

Kube-apiserver.yaml, two probes are used at the same time.