Readiness & Liveness Probes in Kubernetes

Readiness and Liveness Probes in Kubernetes

Cloud Computing, Webinar / By

Whizlabs, on 25 November 2021, conducted a well organised webinar on ‘Readiness and Liveness Probes in Kubernetes’ with Mr. Abhishek Dubey.

Abhishek Dubey works as a Senior DevOps Consultant at OpsTree Solutions. He is a developer and does DevOps training and webinars explaining the concepts in detail. He has been working on multiple open source projects like Kubernetes, Operator Framework for 5 years. He is also one of the GitHub code owners of Prometheus community Helm charts and Operator Framework.

What follows below is his outlook towards Kubernetes and its applications.

What are Probes?

Kubernetes Health

‘Probes’ is the process of checking the health of a Kubernetes-based application, container or pod to see if it is working fine and receiving traffic.

 It has been designed to check the readiness and responsive status of the application and to check if the application is ready to serve the traffic.

For instance, if the application is under a deadlock state, what needs to be done is to restart the application.

This can be achieved by using Probes inside Kubernetes.

There exist two cases:

  • First, when the application is running.
  • Second, the application is performing on the logic that it has been designed for.

For instance, an application is running, but it is not functioning because it has some dependency that is not being fulfilled. It means the actual business logic of the application is not working.

In a general scenario, the application can have two types of failures, be it a Container-Native environment or a Non-Container environment:

  • The application is initialising: The application is started, but it is not able to serve the traffic. But if you still send the traffic to the application when it is in the initial stage, that traffic will fail completely. So, when the application is initialising, you must not send the traffic.
  • The application is live: The application has not crashed and it is running fine but it is not ready to serve the traffic due to some dependency. For instance, there are some deadlocks like the database connection is not working. So, when you send traffic to that application, it will not process any kind of request and will stop responding.

In this case, we can restart the application.

Kubernetes solve these problems with the help of ‘Probes’.

Lifecycle of Container inside Kubernetes Pod

Kubernetes Health Pod

Why are Probes important?

Importance of Probes

Suppose there are two containers Pod A and Pod B, containing two different applications.

For Pod A, the container state is running which means the application process is running but the app is not started yet. For instance, it is doing a database initialisation or populating it or migrating something into the database, but the process is running.

So, should we send the traffic to it?

If we send any kind of traffic to it while it is in the initialisation stage, the application will fail.

So, we have to put some checks that are Readiness Probe and Liveness Probe: 

  • If its status is failed and not checked, this implies that the application is not healthy, the process is running but it is not ready to serve the request. Kubernetes will not send the traffic to this application.
  • Else if the status for both of them is a success, Kubernetes will send the traffic to it.

In a distributed application setup, there exist multiple applications, and one of them is dependent on another. If that application is not working then the main application will also not work. What you need to do for the resolution is restart your application, which means if it is not possible to make a live connection, the process should be restarted for another trial.

Concept of Readiness Probes

Readiness Probes

Kubernetes makes use of the readiness probe to determine if the application is ready to serve the requests.

A Pod is ready when the containers are ready. When the application starts, there could be some ongoing initialisation tasks, for instance, Database population. So, when the initialisation is completed only then can the application accept the traffic.

Concept of Liveness Probes

Kubernetes checks if the process is still in execution state. Liveness ProbesBut what if the application is not ready to serve the traffic?

Suppose there are two pods, and one of them is serving traffic, while the other gets stuck in the Deadlock state because it is not able to connect with the dependent application. Then some requests will succeed because they will go to Pod1, while other ones will fail because they will go to Pod2. In this case, if Kubernetes is not able to determine that the other one is not working, some of the users will get success as a response, while some of them will receive failure as an answer.

So, in the Liveness Probe, you can check if the application is running but whether it is fulfilling the business need or not.

For example, the application process is running, but the dependent application is not running, which implies that the main application is not able to connect to the dependent application, resulting in the main application not being ready to serve the traffic.

So, in this case, based on the status of the Liveness Probe, the Kubernetes will restart the container.

Types of Probes inside Kubernetes

  1. Command Probe: For example, you are deploying a MySQL based application inside the Kubernetes Cluster and the port check is successful but the application is still not responding because some table on the database is still missing. So, here the TCP/IP probe will not work. Here you will use the command probe using a Shell script where you can simply ask to execute the MySQL command and check if the database exists or not. On the basis of this, you can provide an exit code where an exit code of ‘0’ means success otherwise failure.
  2. HTTP Probe: In this probe, we define a Port no. along with the URL. For example, the user makes a request on port 80 on /health url, and if he is getting a 200 user code, which is a healthy user code, it will pass the probe. But if the status code is some 502 or 404, then it means that the application is not responding and it needs to be restarted because it is not ready to serve the traffic. So, here we get to know if the application is ready to serve the traffic or it needs a restart.
  3. TCP/IP Probe: TCP/IP port checks if the port is listening. For example, if you have a 4 layer application, a MySQL, or a mongoDB and you don’t have the layer 7 capability, you cannot make an HTTP request then you have to check for the port it is using. So, you will use telnet to see if the port is listening.

Importance of Probes in Kubernetes Deployment Strategies

Suppose there is a deployment inside the Kubernetes, and we have version 1 inside which there are two pods. Now, when the traffic is being sent to the V1 pod in the initialisation stage, the traffic will be sent only when it is ready. So, if we are not defining the readiness and the liveness probes, and the database is not ready, the requests will start to fail as a consequence.

Importance of Probes

To better understand the concepts and get in-depth knowledge on Kubernetes, go through the hands-on session the instructor has gone through in the Webinar.

The clarity with which the instructor has explained the concept is amazing. Please feel free to watch the complete webinar on the below link:

https://www.youtube.com/watch?v=wdRDcUtTam0

About Abilesh Premkumar

Abilesh holds a Master's degree in Information technology and Master of Philosophy Degree in Computer Science and did his Research on Information security via Collaborative Inference Detection. Also, received an Honorary Doctorate from UNO recognized organization. He contributes to Cloud research and supports building cloud computing tools.

Related Posts

Leave a Comment

Your email address will not be published. Required fields are marked *


Scroll to Top