Content

• Liveness Probe
  • How Liveness Probes Work
  • Using Liveness Probes To Check Pod Health
  • Let’s Implement Liveness Probe
• Readiness Probe
  • How Readiness Probes Work
  • Using Readiness Probes To Check Pod Health
  • Let’s Implement Readiness Probe
• Startup Probe
  • How Startup Probes Work
  • Using Startup Probes To Check Pod Health
  • Let’s Implement Startup Probe
• Combine Liveness & STartup Probe Together
• Conclusion

Liveness Probe

Liveness probes are health checks performed by Kubernetes to determine whether a container in a pod is running and healthy. These probes periodically verify that the application is running as expected and, if necessary, take corrective action to improve the stability and availability of your application.

If a liveness probe fails, Kubernetes assumes that the container is unhealthy and automatically restarts it. This ensures that any temporary issues or crashes are quickly resolved, minimizing downtime and keeping your applications running smoothly.

How Liveness Probes Work

There are three types of liveness probes in Kubernetes:

1. HTTP GET Probes: These probes send an HTTP GET request to the specified path and port on the container. If the probe receives an HTTP response with a status code between 200 and 399, it considers the container to be healthy.
2. TCP Socket Probes: These probes attempt to establish a TCP connection to the specified port on the container. If the connection is successful, the container is considered healthy.
3. Exec Probes: These probes execute a command within the container. If the command returns a 0 exit status, the container is considered healthy. Non-zero exit statuses indicate that the container is unhealthy.

Using Liveness Probes To Check Pod Health

Implementing liveness probes in your Kubernetes deployments can help improve the reliability and resilience of your applications. Here’s how liveness probes can be helpful:

1. Automatic Container Restart: If a container becomes unresponsive or crashes, the liveness probe will detect the issue and trigger an automatic restart. This ensures that your application continues to run with minimal downtime.
2. Detecting Deadlocks: Liveness probes can identify when an application becomes deadlocked and unresponsive. When detected, Kubernetes restarts the container to resolve the issue and keep your application available.
3. Improving Application Stability: By continually monitoring container health, liveness probes help maintain the overall stability of your application. This reduces the likelihood of cascading failures and improves the user experience.

Let’s Implement Liveness Probe

In this example, the liveness probe checks for the file /tmp/healthy. The probe starts 10 seconds after the container starts. The probe runs every 5 seconds, and if it fails, Kubernetes restarts the container.

Readiness Probe

Readiness probes are health checks performed by Kubernetes to determine if a container is ready to accept traffic. While liveness probes focus on ensuring that a container is running and healthy, readiness probes ensure that a container is prepared to handle incoming requests. If a readiness probe fails, Kubernetes will stop routing traffic to the container, preventing users from experiencing errors or degraded performance.

How Readiness Probes Work

Readiness probes work similarly to liveness probes, with three types available:

1. HTTP GET Probes: These probes send an HTTP GET request to the specified path and port on the container. If the probe receives an HTTP response with a status code between 200 and 399, it considers the container to be ready.
2. TCP Socket Probes: These probes attempt to establish a TCP connection to the specified port on the container. If the connection is successful, the container is considered ready.
3. Exec Probes: These probes execute a command within the container. If the command returns a 0 exit status, the container is considered ready. Non-zero exit statuses indicate that the container is not ready to accept traffic.

Using Readiness Probes To Check Pod Health

Implementing readiness probes in your Kubernetes deployments can help improve the performance and reliability of your applications. Here’s how readiness probes can be helpful:

1. Traffic Management: Readiness probes ensure that traffic is only routed to containers that are prepared to handle requests. This helps prevent users from experiencing errors, slow response times, or service degradation.
2. Application Scaling: When scaling your application, readiness probes help Kubernetes determine when newly added containers are ready to receive traffic. This ensures that your application scales smoothly and maintains consistent performance.
3. Rolling Updates: Readiness probes play a crucial role during rolling updates, allowing Kubernetes to determine when a new version of a container is ready to accept traffic. This helps ensure seamless updates with minimal user impact.

Let’s Implement Readiness Probe

In this example, the readiness probe checks for the file /tmp/healthy. The probe starts 10 seconds after the container starts. The probe runs every 5 seconds, and if it fails, Kubernetes considers the container not ready to accept traffic.

Startup Probe

Startup probes are health checks performed by Kubernetes to determine if a container has successfully started up and initialized its application. During the startup phase, a container might require additional time to load data, initialize state, or perform other necessary tasks before being fully operational. Startup probes help ensure that a container is given enough time to complete these tasks before it is considered ready to accept traffic or checked for liveness.

How Startup Probes Work

Startup probes work similarly to liveness and readiness probes, with the same three types available:

1. HTTP GET Probes: These probes send an HTTP GET request to the specified path and port on the container. If the probe receives an HTTP response with a status code between 200 and 399, it considers the container to have successfully started.

2. TCP Socket Probes: These probes attempt to establish a TCP connection to the specified port on the container. If the connection is successful, the container is considered to have started successfully.

3. Exec Probes: These probes execute a command within the container. If the command returns a 0 exit status, the container is considered to have successfully started. Non-zero exit statuses indicate that the container has not yet completed its startup tasks.

Using Startup Probes To Check Pod Health

Implementing startup probes in your Kubernetes deployments can help improve the performance and reliability of your applications. Here’s how startup probes can be helpful:

1. Graceful Initialization: Startup probes give your containers the necessary time to complete initialization tasks before they are considered ready to accept traffic or checked for liveness. This ensures that your application starts smoothly and avoids issues related to premature traffic routing or container restarts.

2. Dependency Management: In some cases, your container might depend on external services or resources to be available before it can fully initialize. Startup probes can help ensure that your container only starts accepting traffic once all dependencies are satisfied.

3. Simplified Health Check Management: Startup probes can simplify health check management by allowing you to use the same probe type and configuration for liveness, readiness, and startup checks, reducing the complexity of your deployment configurations.

Let’s Implement Startup Probe

In this example, the readiness probe checks for the file /etc/sudipta. The probe starts 10 seconds after the container starts. The probe runs every 10 seconds, and and if it fails 5 consecutive times, Kubernetes considers the container to have failed its startup and will restart the container.

Combine Liveness And Startup Probe Together

In this example, Liveness and Startup Probe are combined together to get the max benefit. Here Startup probe will check for the file /tmp/healthy every 10 seconds for 2 times. The first time it will fail because the file is not being created yet at the 10th second. The reason is “sleep 15” mentioned which is telling to go to sleep for 15 seconds and then create the file /tmp/healthy. So when the Startup probe will run for a second time, the file will be there and at this point in time, it will hand over the control to the Liveness probe. 

Now after 30 seconds of sleep, I am deleting the file again. So at that point in time, the Liveness probe will fail and restart the container.

This way you can combine these probes in your YAML file to get most benefit.

Conclusion

Kubernetes health checks, including liveness, readiness, and startup probes, play a critical role in building and maintaining reliable, high-performance containerized applications. Each of these probes serves a specific purpose, ensuring that your application runs smoothly, scales efficiently, and initializes gracefully.

Implementing these health checks in your Kubernetes deployments is an essential best practice for building resilient, self-healing applications. By understanding the differences between liveness, readiness, and startup probes and how they work together, you can optimize your Kubernetes deployments for maximum reliability, scalability, and performance. Embrace the power of Kubernetes health checks and build robust, dependable applications for your users.

In my next blog post, I will be doing deep dive into Pod Lifecycle. Please subscribe to my blog and Youtube channel – Technical Potpourri to get updates about all my upcoming blogs/videos.

Disclaimer

This article is not endorsed by Salesforce, Google, or any other company in any way. I shared my knowledge on this topic in this blog post. Please always refer to Official Documentation for the latest information.