blog

12021-08-08

SEAN K.H. LIAO

k8s probes

The containers you run in kubenernetes have an array of lifecycle hooks you can configure. like lifecycle.postStart, lifecycle.preStop, startupProbe, livenessProbe, readinessProbe.

lifecycle hooks

postStart

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.

preStop

This is easier to handle, but if you have this set, then you probably also want to set terminationGracePeriodSeconds

Probes

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:

startupProbe

You probably want a short period and a high failure threshold for this one to poll until your pods are live. only set 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.

livenessProbe

This determines if your app is "alive", as in kill the pod if this one fails.

readinessProbe

This determines if the pod is in the "Ready" state, and by extension, if traffic should be routed to it.

readiness gates

On the pod level, there are readiness gates. These check the pod.conditions.status for specific conditions to be True. This also means it's only really useful for k8s-aware workloads which can patch their own pods (not available to kubectl)

minReadySeconds

Deployments and Daemonsets also have a minReadySeconds field that gate if the app should serve traffic.