Why do I need 3 different kind of probes in kubernetes startupProbe, readinessProbe, livenessProbe
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
In the world of Kubernetes, understanding how applications are defined, maintained, and monitored is crucial. Probes are essential components that help maintain the health and efficiency of your applications. Kubernetes provides three main types of probes: startupProbe, readinessProbe, and livenessProbe. Each has its unique role and significance in ensuring optimal application performance. Let's dive into why these probes are needed and how they function.
Understanding Kubernetes Probes
Probes in Kubernetes are periodic checks performed by the kubelet on a container. They are implemented to understand the state of a container and determine whether it should be restarted, whether it is ready to receive traffic, or if it has started successfully.
1. Startup Probe
Purpose: The primary purpose of the startupProbe is to determine when an application within a container has successfully started. This is particularly important for applications that have a long initialization process. Using a startupProbe can help ensure that liveness and readiness checks are not executed prematurely, causing unnecessary restarts or failed deployments.
Use Case: Consider a Java application with heavy dependency loads and initialization tasks. It may take several minutes to start up fully. During this period, liveness and readiness probes, if not configured correctly, could mistakenly report the application as unhealthy.
Example:
In this example, the probe waits for 60 seconds before the first check (initialDelaySeconds), executes the probes every 10 seconds (periodSeconds), and allows 30 failures before concluding that the startup failed.
2. Readiness Probe
Purpose: The readiness probe is used to determine if a container is ready to handle requests. If a container is not ready, it is excluded from serving requests through a load balancer. This probe ensures that your application can successfully process requests, avoiding downtime for users.
Use Case: A typical situation would be a database service warming up after a restart. The endpoint might be available, but the service is not ready to accept queries until certain caches or initial data loads are completed.
Example:
In this setup, the readiness probe checks if the TCP port is accessible, starting after a 10-second delay. This ensures that only containers capable of handling traffic are part of the serving pool.
3. Liveness Probe
Purpose: The liveness probe detects if an application is running. If an application is no longer responsive or hangs, this probe triggers a restart to restore functionality. Liveness checks are critical for maintaining zero downtime and self-healing systems.
Use Case: Imagine a Python-based REST API that might occasionally hang due to a deadlock or another unexpected fault. A correctly configured liveness probe would detect this issue and restart the container to restore the application's availability.
Example:
This example uses an executable command to verify health by checking the existence of the /tmp/healthy file. If missing, the container is restarted.
Key Differences and Configurations
Understanding the critical aspects of these probes can improve application orchestration in Kubernetes. Below is a summary table highlighting key differences:
| Probe Type | Purpose | Usage | Common Use Case | Configurable Parameters |
| Startup | Initializing Check | During app startup phase | Apps with long init times | initialDelaySeconds, failureThreshold,
periodSeconds |
| Readiness | Ready State Check | Before accepting traffic | Services needing warm-up | initialDelaySeconds, timeoutSeconds,
periodSeconds, successThreshold, failureThreshold |
| Liveness | Health Check | Continuous operation health | Detecting & recovering hang | initialDelaySeconds, timeoutSeconds,
periodSeconds, successThreshold, failureThreshold |
Additional Considerations
Timeout and Retry Logic
Each probe comes with parameters like timeoutSeconds and failureThreshold that allow you to configure how long the probe waits for success and how many times it retries before taking action. Fine-tuning these settings can drastically impact how probes behave, especially under network issues or high latency.
Choosing the Right Type
Selecting the appropriate probe depends on the application's nature and requirements. Some applications might only need readiness and liveness configurations, while others with complex boot-up sequences might benefit from using a startup probe.
Performance Impact
Improper probe configuration could lead to resource waste and performance bottlenecks. It's essential to balance the frequency and threshold of probes carefully to minimize unnecessary resource usage while maintaining desired availability and reliability.
Conclusion
Probes are vital in Kubernetes for maintaining robust and resilient applications. By implementing and configuring startupProbe, readinessProbe, and livenessProbe appropriately, you can achieve better application health management and uptime, providing reliable service to end-users.

