Liveness and ReadinessProbes
Kubernetes performs health checks to check for the health of the pods.
If the pod is unhealthy, traffic shouldn’t be routed to it, else the end users will encounter errors, which is very bad. Or in other words, traffic should only be routed to pods that are healthy.
Let’s say if there are three replicas of the pods that are running and one of them is unhealthy. In that case, traffic coming to the unhealthy pod should be routed to the healthy pods.
This is where livenessProbes come into picture.
A livenessProbes will run continually for the duration of the pod’s lifetime.
If the livenessProbes fails, K8s will command the entire pod to fail. Infact, it will ask the container to be restarted.
In simpler words, livenessProbes indicates whether a container is running.
If the check fails, the container will be restarted.
Below is a deployment file with livenessProbes configured:
readinessProbes on the other hand indicates whether the container is ready to serve requests.
Configuring readinessProbes to a deployment that has been enabled for autoscale, is necessary because when multiple replicas are created on autoscale, all the pods aren’t ready to receive service requests. It takes time. But they may receive service requests , which in return will throw error.
So, the readinessProbes configuration will help K8s in identifying the pods that are ready to receive service requests.
If the readinessProbes check fails, the container will not be restarted. In such scenario, the pod’s IP is removed from the Service. Therefore, it will not serve any requests anymore.
Re-highlighting an important point: Everytime readiness or livenessProbe is configured for a deployment, a check is performed. liveness check and readiness check.
It’s a good practice to configure both livenessProbe and readinessProbe
