Description
A running container process does not guarantee a working application. Deadlocks, indefinite waits or unresponsiveness can stop service while the process stays alive. A livenessProbe helps the kubelet identify such states and restart the container.
Not every workload needs one. It is separate from restartPolicy handling of exited processes, and a poorly designed check can cause repeated restarts of healthy containers or cascading failures.
Potential impact
- A fault that a restart could resolve may persist until an operator intervenes.
- Treating failure of a shared dependency as a liveness failure can unnecessarily restart many instances.
Remediation
- Use a supported HTTP, TCP or exec check to detect states that require a restart. Do not fail a livenessProbe solely because an external dependency is unhealthy.
- Tune periods and thresholds for actual initialization and recovery times, using a startup probe where needed. Use a readiness probe separately to determine traffic readiness.
Examples
The after excerpt assumes an application that separately implements /health. The default nginx image does not automatically provide it, so prepare the necessary configuration. The existing image and timing values are illustrative.
Before
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: nginx:1.27
ports:
- containerPort: 80
No liveness check detects unresponsiveness. If the process exits, restartPolicy applies separately.
After
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: nginx:1.27
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 10
periodSeconds: 10
HTTP failures that continue through the threshold trigger container restart handling. The path and timing must match actual recovery requirements.