Kubernetes — Liveness and Readiness Probes — Difference

Liveness and Readiness probes are used to control the health of an application running inside a Pod’s container. Both of them are very similar in functionality, and usage.

Liveness Probe

Suppose that a Pod is running our application inside a container, but due to some reason let’s say memory leak, cpu usage, application deadlock etc the application is not responding to our requests, and stuck in error state.

Liveness probe checks the container health as we tell it do, and if for some reason the liveness probe fails, it restarts the container. We can define liveness probe in 3 ways:

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 name liveness, and as the container initialise we use the following command:

- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600

to create a file healthy at path /tmp/healthy, and delete it after 30 seconds.

exec:
  command:
  - cat
  - /tmp/healthy

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

initialDelaySeconds: 3

This is the delay which tells kubelet to wait for 3 seconds before performing the first probe

periodSeconds: 5

This field specifies that kubelet should perform a probe every 5 seconds.

So, according to above example our container will start and work fine for first 30 seconds, and after that liveness probe will fail and restart the container.

Liveness HTTP request

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3

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.

TCP Liveness probe

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

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

Readiness Probe

In some cases we would like our application to be alive, but not serve traffic unless some conditions are met e.g, populating a dataset, waiting for some other service to be alive etc. In such cases we use readiness probe. If the condition inside readiness probe passes, only then our application can serve traffic.

Readiness probe is defined in 3 ways exactly like the Liveness probe above. We just need to replace livenessProbe with readinessProbe like this:

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

Summary

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