A liveness check asks whether an application is still functioning, not merely whether its process exists. An application can stop responding because of a deadlock or an infinite loop while its process keeps running. In Kubernetes, you configure a liveness probe on a regular container in a Pod. Kubernetes runs it periodically; after enough failures, it terminates the container and restarts it if the Pod’s restart policy allows. Liveness probes cannot be defined on init containers. section 6.2.2
Choose a probe that the application can answer:
- HTTP GET requests a specified path and port. A 2xx or 3xx response succeeds; an error response or timeout fails. section 6.2.2
- TCP socket attempts a connection to a specified container port. Use it for a service that accepts non-HTTP TCP connections. section 6.2.5
- Exec runs a command inside the container. Exit code zero succeeds; a nonzero exit code or timeout fails. The command must be available in the container. section 6.2.5
Listing 6.1 Adding a liveness probe to a pod
apiVersion: v1
kind: Pod
metadata:
name: kiada-liveness
spec:
containers:
- name: kiada
image: luksa/kiada:0.1
ports:
- name: http
containerPort: 8080
livenessProbe: #1
httpGet: #1
path: / #1
port: 8080 #1
- name: envoy
image: luksa/kiada-ssl-proxy:0.1
ports:
- name: https
containerPort: 8443
- name: admin
containerPort: 9901
livenessProbe: #2
httpGet: #2
path: /ready #2
port: admin #2
initialDelaySeconds: 10 #2
periodSeconds: 5 #2
timeoutSeconds: 2 #2
failureThreshold: 3 #2
This Pod manifest puts an HTTP GET livenessProbe under each container: one checks the application’s root path on port 8080; the other checks the proxy’s health endpoint on its named admin port. section 6.2.3
Probe settings control when and how quickly a failure leads to termination. initialDelaySeconds delays the first check, periodSeconds sets the interval, timeoutSeconds limits each attempt, and failureThreshold specifies how many consecutive failures are needed. The simple HTTP example uses its defaults: a first request after 10 seconds, checks every 5 seconds, a 2-second timeout, and termination after three failures. section 6.2.3
Watch a failed check cause a restart
Apply the Pod manifest, then run kubectl get events -w. In the proxy example, curl -X POST localhost:9901/healthcheck/fail makes its endpoint return HTTP 503. Events first report failed liveness probes; after the third failure, they report that the container will be restarted. kubectl get po kiada-liveness then shows the Pod running with one restart. Successful checks normally produce no Pod-status or event entry, though their requests may appear in container logs. section 6.2.4
Listing 6.2 Using a combination of a startup and a liveness probe
...
containers:
- name: kiada
image: luksa/kiada:0.1
ports:
- name: http
containerPort: 8080
startupProbe:
httpGet:
path: / #1
port: http #1
periodSeconds: 10 #2
failureThreshold: 12 #2
livenessProbe:
httpGet:
path: / #3
port: http #3
periodSeconds: 5 #4
failureThreshold: 2 #4
For an application that warms up slowly, this manifest gives a startup probe up to 12 attempts at 10-second intervals, then uses a liveness probe that checks every 5 seconds and fails after two attempts. section 6.2.6
A startup probe prevents a slow-starting application from being repeatedly terminated before it can answer liveness checks. While the startup probe runs, the liveness probe does not; liveness checks begin when startup succeeds. This keeps startup allowances separate from fast detection of failures during normal operation. section 6.2.6
Keep the liveness handler dependable. A root-page request can catch a server that no longer answers HTTP, while a dedicated endpoint such as /healthz can check internal components. Do not make it fail because of an external factor, or require authentication that the probe cannot provide: a false failure causes an unnecessary restart. When termination is required, a configured pre-stop hook runs before the main process receives SIGTERM. section 6.2.7 section 6.4.2
