Liveness and Readiness
2 min readJan 17, 2025
service:
liveness:
useHttp: true
endpoint: /lCheck
readiness:
enable: true
useHttp: true
endpoint: /hCheck
livenessFailureThreshold: 3
livenessInitialDelay: 300
periodSeconds: 20
This configuration typically appears in a Kubernetes Helm chart or configuration file for defining liveness and readiness probes for a service. Let’s break it down:
1. service:
This is the parent configuration block, likely defining settings related to a specific service deployed in Kubernetes.
2. liveness:
- This block configures the liveness probe, which determines whether the container is still running and healthy. If the liveness probe fails, Kubernetes restarts the container.
Sub-fields:
useHttp: true
- The liveness probe will use an HTTP endpoint (instead of a TCP socket or command) to check the container’s health.
- Typically, this involves hitting a specific health check URL, like
/healthz
. livenessFailureThreshold: 3
Kubernetes will restart the container if the liveness probe fails 3 consecutive times.livenessInitialDelay: 300
Kubernetes will wait 300 seconds (5 minutes) after the container starts before performing the first liveness probe. This is useful for containers that need time to initialize.periodSeconds: 20
The liveness probe will run every 20 seconds to check the health of the container.
3. readiness:
- This block configures the readiness probe, which determines whether the container is ready to serve requests. If the readiness probe fails, Kubernetes removes the pod from the service’s endpoints, meaning it won’t receive traffic.
Sub-fields:
enable: false
- The readiness probe is disabled in this configuration, meaning Kubernetes will not check if the container is ready to serve traffic.
useHttp: true
- If the readiness probe were enabled, it would also use an HTTP endpoint for the health check.
Behavior Summary
Liveness Probe:
- Enabled and uses an HTTP-based health check.
- Checks every 20 seconds after an initial delay of 5 minutes.
- Restarts the container after 3 consecutive failures.
Readiness Probe:
- Disabled, so Kubernetes will not remove the pod from the service’s endpoints, even if it becomes temporarily unready.