you run in kubenernetes have an array of lifecycle hooks you can configure.
This is called immediately after the container starts. If you try to call the app you're starting but it's not listening yet it will kill the pod.
This is easier to handle,
but if you have this set, then you probably also want to set
These all work pretty similarly.
initialDelaySeconds is counted from container start,
if your startup probe eclipses the initial delay for your live/readiness probes then they have no effect.
What I think are valid combinations:
You probably want a short period and a high failure threshold for this one
to poll until your pods are live.
initialDelaySeconds if you know for sure your app won't be ready for the first X seconds.
Once this one passes, it is never called again and the liveness/readiness probes are called.
This determines if your app is "alive", as in kill the pod if this one fails.
This determines if the pod is in the "Ready" state, and by extension, if traffic should be routed to it.
On the pod level, there are readiness gates.
These check the
pod.conditions.status for specific conditions to be
This also means it's only really useful for k8s-aware workloads which can patch their own pods
(not available to kubectl)
Deployments and Daemonsets also have a
minReadySeconds field that gate if the app should serve traffic.