What is the meaning of the existence of startupProbe?

What is the meaning of the existence of startupProbe? Introduction

Today, when I was sorting out my mind map, I suddenly found a probe startupProbe that I didn't know, so I checked the official explanation: you can define a priming probe that will delay all other probes until Pod finishes booting. After reading this sentence, there is a circle and then asks the following question:

The significance of the startupProbe startup probe is: if it takes 1 minute for Service A to start the probe, we set initialDelaySeconds to start the probe after 10 seconds, and then she finds that the service is abnormal when she detects it, and then starts to restart Pod and falls into a dead loop. But if the meaning is in this place, we can adjust the detection time a little bit, and failureThreshold can set this a few more times. Why set up a separate satrtupProbe?

After discussing to the boss, the answer is as follows.

What is the meaning of startupProbe?

You need to know this as you move on: the biggest difference between startupProbe and livenessProbe is that startupProbe will not continue to probe after the probe is successful, while livenessProbe has been probing throughout the life cycle of pod.

If there is no startupProbe probe, then we only set the livenessProbe probe, then there will be the following problems: if a service takes a long time to start up, the longer it will die and go undetected. Why do you say that? Assuming that it takes 2 minutes for one of our services A to start up, let's start defining livenessProbe as follows

LivenessProbe: httpGet: path: / test prot: 80failureThreshold: 1initialDelay:5periodSeconds: 5

If we define it in this way, then pod 5s will restart according to the restart strategy, and you will find that pod will always be stuck in an endless loop, so we can change the configuration to this according to the above conjecture.

LivenessProbe: httpGet: path: / test prot: 80failureThreshold: 6initialDelay:40periodSeconds: 5

I'm sure you'll say, don't you think that's it? In this way, pod will not fall into a dead loop and start up, and it is true that pod can be started, but have you ever considered such a problem: when we start up, in the later exploration, you need 6 / 5 / 30 seconds to find that the pod is not available. At this time, your service has stopped running for 30 seconds before you realize that this may not be forgiven in production.

And here we only assume that a service A takes 1 minute to get up, but how do you define these values in actual production?

After introducing startupProbe to solve the above two problems, both of them have been solved.

LivenessProbe: httpGet: path: / test prot: 80failureThreshold: 1initialDelay:5periodSeconds: 5livenessProbe: httpGet: path: / test prot: 80failureThreshold: 60initialDelay:5periodSeconds: 5

After we set this up, due to the existence of the startup probe, the program has the startup time of 605s=300s. Once the probe is started successfully, it will be taken over by livenessProbe, so that livenessProbe can find problems in running within 15 seconds. If the startup probe is not successful within 3 minutes, the restart policy of Pod will be accepted for restart.

What is described above is the meaning of the existence of kubernetes startupProbe?

How much I hope you can give us some advice:

Email: zsf18163201@163.comwechat: * × ×