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 probe and liveness probe starts together¹,
• 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^{7, 8}, 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¹⁰

Here is a copy of the possible values, 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