Configure Liveness, Readiness and Startup Probes

Fleeting

• External reference: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
• see,
  • kubernetes :

In short,

readiness and liveness

probe are very much alike,

• readiness probe and liveness probe: start together¹,
• readiness probe and liveness probe: run for the whole lifecycle of the container²,
• but failures in each will trigger different behaviors
  • failure in readiness probe: says to remove the pod from the network (removing its endpoints from the associated services)³
  • failure in liveness probe: says to restart the pod⁴
• therefore both differ in intention
  • liveness probe: is used to restart when something appears to hang⁵,
    • with a counter indicating each time the containers are up again⁶
  • readiness probe: is used to detect when the pod can receive traffic⁷,
    • without specification, it becomes ready when all the containers have started⁸

startup probe⁹

is used to delay the liveness probe and readiness probe^{10, 11}, to mitigate for slow starting pods,

• that way, you can define frequent liveness checks that won’t restart the pod when its startup takes time¹²
• if you don’t need to wait some specific event but some time you can simply use initialDelaySeconds¹³

possible values for the fields of the probes

because I often forget them and have a hard time finding them back.

Configure Probes Probes have a number of fields that you can use to more precisely control the behavior of startup, liveness and readiness

checks:initialDelaySeconds

Number of seconds after the container has started before startup, liveness or readiness probes are initiated. Defaults to 0 seconds. Minimum value is 0.

periodSeconds

How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1.

timeoutSeconds

Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1.

successThreshold

Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup Probes. Minimum value is 1.

failureThreshold

After a probe fails failureThreshold times in a row, Kubernetes considers that the overall check has failed :: the container is not ready / healthy / live. For the case of a startup or liveness probe, if at least failureThreshold probes have failed, Kubernetes treats the container as unhealthy and triggers a restart for that specific container. The kubelet takes the setting of terminationGracePeriodSeconds for that container into account. For a failed readiness probe, the kubelet continues running the container that failed checks, and also continues to run more probes; because the check failed, the kubelet sets the Ready condition on the Pod to false.

terminationGracePeriodSeconds

configure a grace period for the kubelet to wait between triggering a shut down of the failed container, and then forcing the container runtime to stop that container. The default is to inherit the Pod-level value for terminationGracePeriodSeconds (30 seconds if not specified), and the minimum value is 1. See probe-level terminationGracePeriodSeconds for more detail.

— https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

• host: Host name to connect to, defaults to the pod IP. You probably want to set “Host” in httpHeaders instead.
• scheme: Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
• path: Path to access on the HTTP server. Defaults to /.
• httpHeaders: Custom headers to set in the request. HTTP allows repeated headers.
• port: Name or number of the port to access on the container. Number must be in the range 1 to 65535

— https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

Notes linking here

• kubernetes best practices

Permalink