Probe of kubernetes

kubernetes Probe of

Three probe types

• HTTP GET Probe to container IP Address execution HTTP GET request . If the detector receives a response , And the response status code does not represent an error （ let me put it another way , If HTTP Response status code is 2xx or 3xx）, It is considered that the detection is successful . If the server returns an error response status code or does not respond at all , Then detection is considered a failure , The container will restart .
• TCP The socket probe attempts to establish with the port specified by the window TCP Connect . If the connection is successfully established , Then the detection is successful . otherwise , Container restart .
• Exec The probe executes arbitrary commands inside the container , And check the exit status code of the command . If the status code is 0, Then the detection is successful . All other status codes are considered to have failed .

Survival probe

Kubernetes It can be done through the survival probe （liveness probe） Check if the container is still running . It can be for pod Each container in the is assigned a survival probe .
If the probe fails ,Kubernetes The probe will be executed periodically and the container will be restarted .

Additional information about the survival probe ：
Liveness: http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3

Information interpretation ：

• delay： Delay ,delay=0s Part shows that the detection starts immediately after the container is started .
• timeout：timeout=1s, The container must be in 1 Respond in seconds , Otherwise, the detection will be recorded as a failure .
• period：period=10s, Every time 10 Detect the container once a second .
• failure：failure=3, Restart the container after detecting three consecutive failures .

These additional parameters can be customized when defining the probe . for example , To set the initial delay , namely initialDelaySeconds. If the initial delay is not set , The probe will begin to detect the container immediately upon startup , This usually leads to probe failure , Because the application is not ready to start receiving requests . If the number of failures exceeds the threshold , Before the application can respond to the request correctly , The container will restart . There is a scene that you will often encounter ： The container is restarting , But use kubectl describe You will see the container with the exit code 137 or 143 end , And see pod Was forced to terminate , Will also be in pod The list of events will show the container cause liveness Detection fails and terminates . In this case, it is mostly because the initial delay is not set .

Be sure to set an initial delay to indicate the start time of the application .

Ready probe

Ready probe （readiness probe） Will call... On a regular basis , And identify specific pod Whether to receive client requests . When the container's readiness probe returns success , Indicates that the container is ready to receive the request . Obviously, this is something unique to each container ,Kubernetes You can only check whether the application running in the container responds to a simple GET/ request , Or it can respond to a specific URL route , The URL Causes the application to perform a series of checks to determine whether it is ready . therefore , This exact determination of readiness is the responsibility of the application developer .

Why do I need a ready probe ？
If not, add the ready probe to pod in , They become service endpoints almost immediately . If the service starts but is not ready to receive incoming connections , The client request will be forwarded to the pod. Then the client will see “ Connection rejected ” Type of mistake .

Additional information about ready probes ：
Readiness: exec [ls /var/ready] delay=0s timeout=1s period=10s #success=1 #failure=3

Command interpretation ： The ready probe will be executed in the container on a regular basis ls /var/ready command . If the file exists , be ls Command return exit code 0, Otherwise return to non 0 Your exit code . If the file exists , Then the ready probe will succeed , Otherwise it will fail .

The information interpretation in this is the same as that of the survival probe .

The ready probe ensures that the client only works with normal pod Interaction , And never know there's a problem with the system .

The difference between survival and ready probes

Unlike survival probes , If the container fails the readiness check , Will not be terminated or restarted . This is an important difference between the two probes .

Survival probes maintain by killing abnormal containers and replacing them with new normal containers pod Normal work , And the ready probe ensures that only the benefits of preparation are desired pod To receive a request . This is most necessary when the container starts .

Reference books ：《Kubernetes in action》