Difference between Liveness and Readiness Probes

Liveness, Readiness probes are used to check the health of an application and to maintain the application's highly available

Let’s discuss this in more detail

Liveness Probe:

Suppose that a Pod is running our application inside a container, but due to some reason i.e. memory leak, CPU usage, application deadlock, etc the application is not responding to our requests and is stuck in an error state.

The Liveness probe checks the container's health as we tell it to, and if for some reason the liveness probe fails, it restarts the container.

Liveness command

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 3
      periodSeconds: 5

We are creating a container with the name liveness, and as the container initializes we use the following command:

# The following command create a file "healthy" in "/tmp" folder nd delete it after 30 seconds.
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600

There are 3 ways we can perform liveness probes.

exec:

exec:
  command:
  - cat
  - /tmp/healthy

This command in the liveness probe tells to open a file at path /tmp/healthy, and if it can’t open a file the liveness probe will fail and the container will restart.

httpGet:

In this case, the kubelet will send HTTP GET request to /healthz endpoint at port 8080 of the application running inside the container. If the response is an error liveness probe will. Otherwise, it will consider the application to be alive.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3 ## The first inital health check performed after 3 seconds after the container is run 
  periodSeconds: 5 ## kubelet should perform health check every 5 seconds

tcpSocket:

In this case, the kubelet will try to open a TCP socket at port 8080 in the container running the application. If it succeeds the application will be considered healthy, otherwise, the probe will fail, and the container will restart.

livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20

Readiness Probe:

Readiness probes help you to make the application stable before serving user requests. in other words, we would like our application to be alive, but not serve traffic unless some conditions are met.

Example:

1. The application should be ready only if it finds a file in a specific path.
2. Before an application is ready it should copy some data from external sources and then serve a request

The readiness probe is defined in 3 ways exactly like the Liveness probe above. We just need to replace livenessprobe with readinessprobe

Let’s see how the readiness probe works in practical.

in the following example, our application becomes ready only if it finds a file “readinessprobe” in “/tmp” folder.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness-exec
  namespace: cluster-autoscaler-testing
spec:
  containers:
  - name: readiness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/readinessProbes
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/readinessProbe
      initialDelaySeconds: 3
      periodSeconds: 5

There are 3 ways we can perform readiness probes.

exec:

In this case, the commands tell the readiness probe to open a file at path, and if it can’t the readiness probe will fail and the container will restart.

readinessProbe:
      exec:
        command:
        - cat
        - /tmp/readinessProbe

httpGet:

In this case, the kubelet will send HTTP GET request to /healthz endpoint at port 8080 of the application running inside the container. If the response is an error readiness probe will. Otherwise, it will consider the application to be alive.

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3 ## The first inital health check performed after 3 seconds after the container is run 
  periodSeconds: 5 ## kubelet should perform health check every 5 seconds

tcpSocket:

In this case, the kubelet will try to open a TCP socket at port 8080 in the container running the application. If it succeeds the application will be considered healthy, otherwise, the probe will fail, and the container will restart.

readinessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20

Summary

Both liveness & readiness probes are used to control the health of an application. A failing liveness probe will restart the container, whereas a failing readiness probe will stop our application from serving traffic.