Kubernetes health probes using Liveness and Readiness

Pod health issues in Kubernetes are critical, sometimes a pod starts but its container inside crashes and fails to run. However, if the pod is running it may look fine even though the container and application inside are not running and not accessible from other pods. When the pod crashes Kubernetes restart the pod automatically but if the container inside the pod crashes the developers must restart it manually. The question is how can we know when the container is not running even though the pod is running?

Liveness Probe

Pod health issues in Kubernetes are critical, sometimes a pod starts but its container inside crashes and fails to run. However, if the pod is running it may look fine even though the container and application inside are not running and not accessible from other pods. When the pod crashes Kubernetes restart the pod automatically but if the container inside the pod crashes the developers must restart it manually. The question is how can we know when the container is not running even though the pod is running?

Liveness Probe

Kubernetes manages in a very intelligent way all its resources, it knows when a pod dies and restarts it. To solve the issue of failed applications Kubernetes uses Liveness Probe. The probe must be defined at the container level and it’s a very simple script that pins the application endpoint every few seconds. It can be defined in 3 different ways:

1. Exec probes — check is done via simple command execution, for example, running a script that checks the application’s health status.

Kubernetes manages in a very intelligent way all its resources, it knows when a pos die and restart it. To solve the issue of failed applications Kubernetes uses Liveness Probe. The probe must be defined at the container level and it’s a very simple script that pins the application endpoint every few seconds.

2. TCP probes — TCP socket attribute with the port where the application is running, kubelet will open the socket of your container on the specific port, if it succeeded to establish a connection using the port the container is considered healthy. If not the probe fails.

3. HTTP probes — check the application heath on the HTTP endpoint. Kubectl sends an HTTP request using the httpGet attribute that defined the path and the port of the application.

A limitation of liveness is that it can help Kubernetes know that the application is running after it started, but it can not check the application starting process itself. That’s where the readiness prob is coming in.

Readiness Probs

It lets Kubernetes know that the app is ready to receive traffic, this is important because if your application needs two minutes to start all the requests will fail during those 2 minutes and you’ll get errors without knowing the right status of the app. The readiness probe is similar to the Liveness prob it just does it during the app start process

Combination of the two

The YAML above includes Liveness and Readiness probing. The readiness probe uses tcpSocket with a 10-sec delay to allow the container to be up and running after that 5-sec sequence health check. Once the container is up and running the livenessProbe takes action and check health using tcpSocket every 15 sec after 5-sec delay.

Join my Linkedin