Why do we use startup probe and not the liveness probe with initialDelaySeconds parameter

user_2343300 0
Viewed 744

I have a question regarding the status probe.

When I read the documentation, I understand that it's made mainly for applications that take a long time to start (like legacy applications). So in order to not kill the application (the container running it), we set up a startup probe to for example 5 minutes so the application has all the time to be able to start.

My question is: Why can't we just set a liveness probe (instead of using both liveness and startup probes) with the initialDelaySeconds parameter and set its value to something like 300 seconds?

probe kubernetes startup
1 Answers

Note the example given in kubernetes docs:

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

The key difference between two probes here is not the delay - it's the fault tolerance. For startup probe, it's expected that app starts slow... sometimes. But most of the time it might be fast enough actually!

So the startup probe tries 30 times, waiting 10 seconds between each attempt, and considers its job completed on the first success, passing the token to liveness probe immediately after that.

With your approach, even if app has already started, the very first liveness probe on that won't be fired until 300 seconds have passed - regardless of whether or not app actually took ~300 seconds to start.

Of course, for apps that always require considerable amount of startup time, this approach might make sense.

user_12290230
Related