Kubernetes (also known as K8s) is an open-source Container Management tool. It helps us automate all the processes like deployment, load balancing, rolling update, etc. We can basically deploy, scale and manage containerized applications.
In Kubernetes, Liveness and Readiness probes are usually used for monitoring the health of the pods and are quite similar in nature as well. If the pod goes down or if the connection is interrupted these probes help efficiently to know it is down and also help recover it. They can be specified in the yaml files itself.
How Do Liveness and Readiness Probes Work?
Liveness probe as the name suggests tells us if the pod is alive or not. It basically tells us if the pod is in a healthy state or not. It can be used in multiple ways but is defined under spec.containers.livenessprobe in yaml configuration file.
Readiness probe on the other hand lets us check whether our application pods are ready to take any new request. It could happen if our Kubernetes pod is alive but due to some network error or congestion, it is not able to process any new requests, So, the readiness probe helps us know this. It is defined under spec.containers.readinessprobe in yaml configuration file. It will helps while using kubernetes deployments.
Kubernetes-Using Liveness Probe
To use liveness probe for our application, we need to specify them in the yaml configuration file in the place defined above. To check if the pod is alive or not, we can specify a command or a custom script to run periodically. The container is killed by the kubelet and is subject to its restart policy if the liveness probe fails.
First of all, for adding a liveness probe we could add something like this:
spec:
containers :
name: “demo_container”
livenessProbe:
failureThreshold: 6
exec :
command: [“bash”, “-c”, “./liveness-script.sh”]
periodSeconds: 5
In the above, we added liveness probe for one of the containers and specified the failureThreshold as 6 which means it will check 6 times when the pod fails before declaring it as failed and periodSeconds as 5 on how periodically we want to check the liveness probe. Now, coming to the actual command which will run to check the liveness probe – in this case it runs a script (we can also run a set of commands directly). The content of the script would differ based on type of container and how do we verify the pod is alive for that.
We can have a command as simple as “ping” for the url or more complex scripts. The liveness probes also differ if we need to check a HTTP connection or a TCP connection.
Suppose for checking an HTTP request we can use something similar to this:
livenessProbe:
httpGet:
path: /health
port: 8000
This will make an HTTP Get request on the specified path and port to check the aliveness.
On the other hand, for a TCP connection request we can do this:
livenessProbe:
tcpSocket:
port: 8080
This will try opening a TCP socket connection on the specified port and if it succeeds, then the pod is alive
Kubernetes-Using Readiness Probe
To use readiness probe for our application, we need to specify them in the yaml configuration file in the place defined above. To check if the pod/container is ready to take a request, we can specify a command or a custom script to run periodically. And if the pod is not ready, it won’t get any traffic from the kubernetes services.
First of all, for adding a readiness probe we could add something like this:
spec:
containers :
name: “demo_container”
readinessProbe:
exec :
command: [“bash”, “-c”, “./readiness-script.sh”]
periodSeconds: 5
failureThreshold: 5
It is very similar to how we define livenessProbe, just using readinessProbe instead.
Using HTTP and TCP connections also work in similar manner for readiness probes as liveness probes. For the same pod/container, both the probes can be utilised simultaneously. Using both can guarantee that traffic does not go to a pod which is not ready and that containers are restarted when they encounter problems.
Important Configuration Settings
- SuccessThreshold: if the probe failed last time, the successes required for it to be successful.
- PeriodSeconds: the period of time between each run of the probe.
- InitialDelaySeconds: it tells how much time needs to be waited after startup for the first probe to run
- FailureThreshold: if the probe failed last time, the failures required for it to be called failed.
- /tmp/healthy: this path/command can be used on kubernetes which provides the health of the pods.
- TimeoutSeconds: the time after which the probe can timeout if it doesn’t run
Advantages of Using Liveness and Readiness Probes
As mentioned earlier liveness and readiness probes are used to check the health of the resources in Kubernetes, but this also has many added advantages. Some of them include:
- Using liveness probes can help us improve the availability of our application and containers.
- Readiness probes can actively help in troubleshooting. If there’s some failure in a readiness probe it lets us know there is an issue with the service and can help fix it.
- Liveness probes can also help us verify if the services restart properly if any of the pods are unhealthy.
- On the other hand, readiness probe help us verify if the services run as designed.
Best Practices
- Use an optimal periodSeconds parameter. This should not be too low that the resources get wasted but should not be too high that the unhealthy pods go unnoticed.
- Try to use maximum number of parameters to fine tune the probes. For example, you can use timeoutSeconds and give it the smallest possible value which you think would be enough for the probe to run.
- Also, try to use shorter commands or scripts which run in the probes periodically. This will ensure that the probes don’t take longer to run and therefore any containers that are unhealthy will be recognized sooner.
- Make sure that the url (for HTTP connection) or any command we use for the probes is different than the main application. This will help if the main app goes down, the probes can still work and tell us the issue.
- Try to use different types of probes – we have command/scripts, HTTP, TCP and also gRPC and all of these are helpful in different scenarios so try to utilize them fully.
- We don’t need to add a probe for each container – some containers which are low priority and have shutdown policy the probes are not really required. If we add it, it would just be an overhead for the resources.
Conclusion
In summary, we saw that both liveness and readiness probes can be able to check the health of the pods. If the liveness probe fails, the container will be restarted; however, if the readiness probe fails, our application won’t be able to serve traffic. These probes can greatly increase efficiency of the application if used properly.
FAQs On Kubernetes Liveness and Readiness Probes
1. What Is The Difference Between Readiness And Liveness Probes In Kubernetes?
Readiness probe checks weather the container is running properly or not and liveness probe checks weather application is ready to accept the request or not.
2. What Are The Three Types Of Probes In Kubernetes?
There are three types of probes are available. They are:
- Liveness Probe
- Readiness Probe
- Startup Probe