top of page

Understanding Health Probes in Kubernetes - Blog #12

Updated: Apr 12






Introduction


When deploying applications to a Kubernetes cluster, it is important to configure health probes along with resource limits to ensure optimal performance. This article will discuss the different types of health probes and their significance in Kubernetes.




Types of Health Probes:

  1. Startup Probe: This probe ensures that the application is starting up correctly. It only runs once during startup.

  2. Readiness Probe: This probe checks if the application is ready to handle traffic. It is continuously active and if it fails, Kubernetes stops directing traffic to the application until it is ready again.

  3. Liveness Probe: This probe checks if the application is running smoothly. It is also continuously active, and if it fails, Kubernetes treats the application as stalled and attempts to restart it.



Common Pitfalls:

  1. Not considering third-party services like databases in the readiness probe.

  2. Having the readiness and liveness probes share the same endpoint.

  3. Using an old health endpoint from a virtual machine deployment instead of a container.

  4. Failure to utilize built-in safety features of the framework.

  5. Overcomplicating health checks, leading to internal denial of service attacks within the cluster.

  6. Triggering a domino effect of failures with liveness probes checking external services.



Use Case:

Suppose the Login service is used by three other services. If the liveness probe is configured to verify dependencies, it could lead to all services being marked as down even though only one had issues. To avoid this, circuit breakers can be used to separate liveness from responsiveness.

Conclusion: Configuring health probes is critical for optimal performance of applications in a Kubernetes cluster. Knowing the significance of each type of probe and avoiding common pitfalls can help ensure smooth functioning of the cluster.








Continuous Blog Series :

Blog #1 : Kubernetes Design Pattern Series - An Overview

Blog #2 : K8s Design Pattern Series - Fundamental Pattern

Blog #3 : K8s Design Pattern Series - Structural Pattern

Blog #4: K8s Design Pattern Series: Behavioral Patterns

Blog #5: K8s Design Pattern Series: Higher Level Patterns

Blog #6: K8s Design Pattern Series: Summary

Blog #7: K8s Anti-Design Pattern Series

Blog #8: K8s Anti-Design Pattern Series - Putting the Configuration into the Images of the Containers

Blog #9: K8s Anti-Design Pattern Series - Connecting Applications to Kubernetes Features/Services without Justification

Blog #10: K8s Anti-Design Pattern Series - Mixing Infrastructure and Application Deployment

Blog #11: K8s Anti-Design Pattern Series - Deploying without Memory and CPU Limits

Blog #12: K8s Anti-Design Pattern Series - Understanding Health Probes In Kubernetes

Blog #13: K8s Anti-Design Pattern Series - The Pitfall of ignoring Helm in Kubernetes Package Management

Blog #14: K8s Anti-Design Pattern Series - Why Deployment Metrics matter in Kubernetes

Blog #15: K8s Anti-Design Pattern Series - To Kubernetes or not to Kubernetes weighing Pros and Cons

Blog #16:K8s Anti-Design Pattern Series - Connecting Applications to Kubernetes Features/Services

Blog #17: K8s Anti-Design Pattern Series - Manual Kubectl Edit/Patch Deployments

Blog #18: K8s Anti-Design Pattern Series - Kubernetes Deployments with Latest-Tagged Containers

Blog #19: K8s Anti-Design Pattern Series - Kubectl Debugging

Blog #20: K8s Anti-Design Pattern Series - Misunderstanding Kubernetes Network Concepts

Blog #21: K8s Anti-Design Pattern Series - Dynamic Environments in Kubernetes why Fixed Staging is an Anti-Design

Blog #22: K8s Anti-Design Pattern Series - Combining Clusters of Production and Non-Production

3 views0 comments

Recent Posts

See All
bottom of page