Skip to main content

Health Probes

Readiness Checks on Kubernetes

Readiness probes are crucial in Kubernetes as they are called periodically, impacting container availability. Failing readiness checks make containers temporarily unavailable, preventing incoming requests from reaching your application. It’s essential to consider what checks to include in readiness probes to avoid unnecessary downtime.

Considerations:

  • Include exclusive/hard dependencies for your service in readiness checks.
  • Avoid including soft dependencies; handle their unavailability in code for a better customer experience.

Good Example: - A private cache/database (e.g., Redis or Postgres) exclusive to the application.

Bad Example: - Shared components like IDAM, S2S, or CCD. - Another API that your team owns

Add Database Check to Readiness Probe

Enhance your application’s health by incorporating a database health check through a readiness probe, with a focus on monitoring database indicators. Implementation guidance can be found in this example.

Liveness Probe

The “Liveness” state of an application indicates whether its internal state allows it to work correctly or recover by itself if failing. A broken “Liveness” state suggests the application cannot recover, prompting infrastructure to restart the application.

This page was last reviewed on 19 June 2024. It needs to be reviewed again on 19 December 2024 by the page owner platops-build-notices .
This page was set to be reviewed before 19 December 2024 by the page owner platops-build-notices. This might mean the content is out of date.