Liveness probe executed before startup probe is successful?

[mloskot]

On https://www.containiq.com/post/kubernetes-startup-probe I read:

Startup probes: Startup probes provide a way to defer the execution of liveness and readiness probes until a container indicates it’s able to handle them. Kubernetes won’t direct the other probe types to a container if it has a startup probe that hasn’t yet succeeded.

But, this is not what I'm observing.

It takes at least a minute (up to 5 minutes) for my container and service to fully start-up, so I configure the startup probe as follows:

startupProbe:
  exec:
    command:
    - cmd
    - /c
    - dir
    - C:\STARTED.txt
  initialDelaySeconds: 30
  failureThreshold: 30
  periodSeconds: 10

I also have liveness probe configured

livenessProbe:
  httpGet:
    path: /healthz
    port: 4325
  periodSeconds: 10

The problem is that see this error as soon (i.e. within 5-15 seconds) as Kubernetes creates the container with my app:

Liveness probe failed: Get "http://10.0.16.19:4325/healthz": 
  context deadline exceeded (Client.Timeout exceeded while awaiting headers)

I can avoid the error with setting long enough initialDelaySeconds, but I'd rather avoid such hack.

As far as I understand all the web resources I've found and read, configuring startupProbe should effectively delay kicking in the liveness and readiness probe.

Could anyone shed any light on why the startup probe could fail to delay the liveness probe?

[philwelz]

i think the livenessProbe kicks in bcs the startupProbe succeeded. I would suggest that the startup and livenessProbe use the same endpoint ( /healthz in your case), but the startupProbe have a less strict failure threshhold which prevents a failure on startup. Smtg like described here.

[mloskot]

I would suggest that the startup and livenessProbe use the same endpoint

Simple, but very practical suggestion. Thanks!