1. Readiness Probe
Readiness Probes are employed to ascertain when a Pod is prepared to handle incoming traffic. If a Pod is deemed unprepared, it will be excluded from receiving traffic from a Service and won't participate in load balancing.
To ensure that the application within a Pod is ready to serve requests, Kubernetes evaluates the conditions of a readiness probe (such as an HTTP GET request, a TCP socket check, or the execution of a command) to determine if the application is ready. If the probe is successful, the Pod is added to the list of ready Pods and is eligible to receive traffic.
A readiness probe can be configured within the container's specification section of a YAML deployment. For instance:
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
- httpGet: This section defines an HTTP-based health check.
- path: Specifies the URL path that Kubernetes will request to determine the Pod's readiness. /health is a common endpoint for health checks.
- port: Indicates the port number where the application is listening for requests.
- initialDelaySeconds: Sets a delay before the first health check to allow the application sufficient startup time.
- periodSeconds: Defines the interval between consecutive health checks.
2. Liveness Probe
Liveness Probe is used to determine when a Pod has crashed or hung and needs to be restarted. When the liveness probe fails, Kubernetes will restart the Pod to restore its operational state.
Kubernetes employs liveness probes to maintain the health of Pods. These probes, configurable as HTTP GET requests, TCP socket checks, or custom commands, determine if the application container within a Pod is still running and responding. Upon repeated failures, Kubernetes schedules a Pod restart.
You can configure the liveness probe in the spec section of the container in a YAML deployment. For example:
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
- path: /health - This is the HTTP endpoint that Kubernetes will send a GET request to check the liveness of the Pod. Your application should define this endpoint and return an HTTP status code to indicate whether it's running. A 200 OK status is commonly returned if the application is healthy.
- port: 8080 - The port on which your application is listening and where Kubernetes will send the GET request. This port must match the port your application is using to listen for HTTP requests.
- initialDelaySeconds: 15 - This is the number of seconds Kubernetes will wait after the Pod starts before it begins executing the liveness probe. In this example, Kubernetes will wait 15 seconds after the Pod starts to check its liveness. This delay ensures the application has enough time to start up and be ready to serve requests.
- periodSeconds: 20 - This is the interval in seconds between liveness probe checks. In this example, Kubernetes will perform a liveness check every 20 seconds. If the Pod doesn't respond correctly at any check, Kubernetes will perform recovery actions (like restarting the Pod).
3. Commonly used conditions for checking Liveness and Readiness Probes
3.1 Conditions for Readiness Assessment
A Readiness Probe checks if an application is ready to serve traffic. Here are the common conditions you would check:
+ Database Connectivity: Verify that the application can successfully connect to the database (or other services the application depends on). This ensures the application has all necessary connections and can perform database operations.
+ Resource Initialization: Ensure that all required resources, such as external services, configuration files, or network services, have been initialized and are ready.
+ Startup Completion: Check that the application has finished the startup process and is no longer in a starting or configuring state.
+ Dependent Services: Ensure that all external services the application depends on (like APIs, message brokers, or web services) are functioning and accessible.
@GetMapping("/readiness")
public ResponseEntity<String> readiness() {
boolean dbReady = checkDatabaseConnection();
boolean externalServiceReady = checkExternalService();
if (dbReady && externalServiceReady) {
return ResponseEntity.ok("Application is ready");
} else {
return ResponseEntity.status(503).body("Application is not ready");
}
}
private boolean checkDatabaseConnection() {
return true;
}
private boolean checkExternalService() {
return true;
}
3.2 Conditions for Liveness Assessment
Liveness Probe checks whether an application is still alive and hasn't hung. This ensures that the application is running and hasn't entered a non-responsive or hung state.
- Application Health: It verifies that the application can respond to HTTP requests or health check commands. If the application is unresponsive, it may be hung or malfunctioning.
- System Resources: In some cases, it can check basic system resources to ensure the application isn't experiencing resource exhaustion or deadlocks.
- Process State: It confirms that the application can process requests and isn't encountering issues like deadlocks or other critical problems.
@GetMapping("/liveness")
public ResponseEntity<String> liveness() {
return ResponseEntity.ok("Application is alive");
}
4. Conclusion
To conclude our discussion on Readiness and Liveness Probes in Kubernetes, we can see that implementing these mechanisms correctly is crucial for ensuring the stability and performance of containerized applications. Readiness Probes determine when a Pod is ready to receive traffic, while Liveness Probes safeguard the application from hanging or unresponsive states by restarting Pods when necessary. Configuring these probes correctly not only enhances Pod management but also improves reliability and user experience.
Understanding and applying these techniques will help you optimize your Kubernetes system, ensuring that your application runs smoothly and responds quickly to user requests. Hopefully, this article has provided you with the necessary information to effectively deploy and manage probes in your Kubernetes environment.
