Skip to main content

Liveness, Readiness and Startup Probes

Startup Probe

The startup probe checks if the application inside the pod has finished initialization. This is useful for applications that have a longer startup time and may need additional time to be ready to receive traffic.

The Kubelet uses the startup probe to know when a container application has started. If a startup probe is configured, readiness probe and liveness probe will not start until the startup probe is satisfied, ensuring that these probes don't interfere with application initialization. This can be used to adopt liveness checks on slow-starting containers, preventing them from being killed by the Kubelet before they are up and running.

Readiness Probe

The readiness probe is used to indicate when a pod is ready to serve traffic. It is used to ensure the pod is ready to receive connections and network traffic. A load balancer should only send traffic to a pod that is ready to process it, meaning it has fully initialized.

A common pattern for liveness probes is to use a low-cost HTTP endpoint (healthcheck), but with a higher failureThreshold. This ensures the pod is observed as not ready for some period of time before being forcefully terminated.

The Kubelet uses readiness probe tests to know when a container is ready to start accepting traffic. A pod is considered ready when all its containers are ready. One use of this signal is to control which pods are used as backends for services. When a pod is not ready, it is removed from service load balancers.

Liveness Probe

The liveness probe is responsible for checking if the pod is alive and healthy. If the liveness probe fails, Kubernetes restarts the pod to restore the healthy state.

The Kubelet uses the liveness probe to know when to restart a container. For example, liveness probes can detect a deadlock, where an application is running but unable to make progress. Restarting a container in this state can help make the application more available, despite bugs.

In summary, the readiness probe checks if the pod is ready to accept traffic, while the liveness probe checks if the pod is alive and functional, but they are only used after the startup probe.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: registry.k8s.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 1 # Number of attempts before killing the pod. The default is 3.
EOF