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

2/20/2021

I have a question regarding the status probe. When I read the documentation, I understand that it's made mainly for applications that takes 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 ? We could use the initialDelaySeconds parameter and set its value to something like 300 seconds ?

Thank you for your answers

-- d3vpasha
kubernetes
probe
startup

1 Answer

2/20/2021

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.

-- raina77ow
Source: StackOverflow