Kubernetes - Liveness and Readiness

Posted on In

configure liveness, readiness and startup probes for Containers

Health Checks are the easiest ways to let the system know if an instance of your app is working. Defining Health check increase the system’s reliability and uptime.

There are two types of Health Checks

  • Liveness
  • Readiness

Liveness probes let Kubernetes know if your app is alive or dead. If you app is alive, then Kubernetes leaves it alone. If your app is dead, Kubernetes removes the Pod and starts a new one to replace it.

Readiness probes are designed to let Kubernetes know when your app is ready to serve traffic. Kubernetes makes sure the readiness probe passes before allowing a service to send traffic to the pod. If a readiness probe starts to fail, Kubernetes stops sending traffic to the pod until it passes.

You can have both Liveness and readiness probe for the same container.

There are three types of Probes

  • HTTP
  • Command
  • TCP

Default HealthCheck

A container starts its process usually with Dockerfile’s CMD or ENTRYPOINT. If the process returns non zero code, then Kubernetes determines the container fails. Kubernetes will decide whether to restart the Pod based on restartPolicy field.

Command Probe

exec-liveness.yaml: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  labels:
    test: liveness
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: 5
      periodSeconds: 5

This pod creates file /tmp/healthy, sleeps for 30 seconds, then remove the file.

The liveness probe will start after 5 second initial delay. The probe have a period of 5 second. The After 30 seconds, when the file is removed, liveness probe will fail. The pod will become unhealthy and gets restarted.

Http Probe

A more common use case will be probe the http service.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: v1
kind: Pod
metadata:
  name: liveness
  labels:
    test: liveness
spec:
  containers:
  - name: liveness
    image: nginx
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5

Readiness Probe

Readiness probes are configured similarly to liveness probes. The only difference is that you use the readinessProbe field instead of the livenessProbe field.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: v1
kind: Pod
metadata:
  name: readiness
  labels:
    test: readiness
spec:
  containers:
  - name: readiness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy;sleep 600
    readinessProbe:
      exec:
        command:
          - cat
          - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

Check the pod status. Readiness probe will fail after 30 seconds. Status will become not ready.

1
2
3
$ kubectl get pods
NAME        READY   STATUS    RESTARTS   AGE
readiness   0/1     Running   0          2m46s

readinessProbe and livenessProde can be the same:

1
2
3
4
5
6
7
8
9
10
11
12
readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 1
  timeoutSeconds: 1
livenessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 1
  timeoutSeconds: 1

References