Understanding Kubernetes HTTP GET Liveness Probe. This is an important container health check mechanism used to detect whether an application is still running normally and to restart the container in case of failure to ensure service availability.
🔍Kubernetes HTTP GET Liveness Probe Explained
1 What is an HTTP GET Liveness Probe
The HTTP GET Liveness Probe is a mechanism used by Kubernetes to check the health status of container applications.The kubelet periodically sends HTTP GET requests to the application running inside the container, determining the health of the container based on the response. If the probe fails continuously beyond a specified threshold, Kubernetes will restart the container to attempt to restore service, which is a key difference from the readiness probe (Readiness Probe): when the readiness probe fails, the container is not restarted but is simply removed from the Service endpoints.
2 HTTP GET Liveness Probe Working Principle
The kubelet acts as an agent on the node, responsible for performing liveness probe checks:
- Regular Probing: Based on the configured time interval, it sends HTTP GET requests to the specified port and path of the container.
- State Determination: If a response is received and the status code is 2xx or 3xx, the probe is considered successful. Otherwise (e.g., 4xx, 5xx or no response) it is deemed a failure.
- Failure Handling: When the number of consecutive failures reaches the set threshold (failureThreshold), Kubelet will kill the container and restart it according to its restart policy (RestartPolicy).
3 Configuration Parameters Explained
When configuring the HTTP GET Liveness Probe, you can adjust the following key parameters to suit the characteristics of your application. These parameters collectively define the behavior, sensitivity, and fault tolerance of the probe.
|
Parameter Name (YAML Field) |
Default Value |
Description and Configuration Recommendations |
|
initialDelaySeconds |
– |
The waiting time from container startup to the first probe. This is a very important parameter that must be set long enough to ensure that your application has completed initialization and can respond to health check requests, avoiding being mistakenly restarted during the startup phase. |
|
periodSeconds |
10s |
The time interval between two probes. This determines the frequency of probing. It should be adjusted based on the stability of the application and how quickly you want to detect failures. |
|
timeoutSeconds |
1s |
The maximum time to wait for a response for each probe request. If no response is received within this time, it is counted as a failure for this probe. If your application responds slowly, you may need to increase this value appropriately. |
|
successThreshold |
1 |
The number of consecutive successful probes required to consider the container as having transitioned from a failed state to a successful state. For liveness probes, this value must be 1. |
|
failureThreshold |
3 |
The number of consecutive failures after which Kubernetes will restart the container. Allowing a certain number of failures can prevent unnecessary restarts due to temporary fluctuations (such as network jitter or momentary high load). |
4 Configuration Example
Below is an example of a Pod definition that includes an HTTP GET Liveness Probe:
yaml
apiVersion: v1
kind: Pod
metadata:
name: my-app-with-liveness
labels:
app: my-app
spec:
containers:
– name: my-app-container
image: my-app-image:latest
ports:
– containerPort: 8080
name: app-port
#Define the liveness probe
livenessProbe:
httpGet: # Probe using the HTTP GET method
path: /healthz # Health check path (provided by the application)
port: 8080 # Health check port
# scheme: HTTP # Optional:HTTP or HTTPS, defaults toHTTP
# httpHeaders: [] # Optional: Custom request headers
initialDelaySeconds: 15 # Wait for15 seconds after container startup to start the first probe
periodSeconds: 20 # Probe every20 seconds
timeoutSeconds: 5 # Probe request timeout is5 seconds
failureThreshold: 3 # Restart the container only after 3 consecutive failures
In this example, kubelet will start sending HTTP GET requests to the 8080 port at the /healthz path of the container every 20 seconds after waiting for 15 seconds post container startup. If there are 3 consecutive failed requests (timeout of 5 seconds without response or returning an error status code), kubelet will kill and restart the container.
5 Best Practices and Considerations
- Set an appropriate initial delay (initialDelaySeconds): This is the most error-prone and critical area. Ensure that this value is greater than the maximum time your application needs to start to avoid being marked unhealthy and entering a restart loop while the application is still loading.
- Define a dedicated health check endpoint: It is recommended that applications provide a dedicated endpoint for health checks (such as /healthz or /api/health). This endpoint should be lightweight and require no authentication, reflecting the status of key internal components of the application (such as database connections, cache status, etc.).
- Keep the probe lightweight: Probing operations should consume minimal computational resources and complete in a short time (the default timeout is only 1 second). Avoid performing heavy operations in the health check logic.
- Reasonably configure timeouts and failure thresholds: Adjust timeoutSeconds and failureThreshold based on the response characteristics of the application. For applications that occasionally have slow requests, appropriately increasing the timeout and failure threshold can prevent unnecessary restarts.
- Use in conjunction with readiness probes: Liveness probes are responsible for restarting failed containers, while the readiness probe (Readiness Probe) determines whether the Pod is ready to receive traffic. It is generally recommended to configure both types of probes simultaneously to ensure that only fully prepared Pods are added to the Service load balancing pool.
- Note: Liveness probes cannot solve all problems: Liveness probes are primarily used to handle application-level failures within nodes (such as application deadlocks). For cross-node network issues, resource shortages, or failures of backend dependent services (such as databases), other mechanisms are usually needed to address these issues.
6 Debugging Tips
If a Pod is frequently restarting, you can use the following commands to troubleshoot:
- Check Pod events and status:
bash
kubectl describe pod <pod-name>
Focus on the Events section and the container’s Restart Count.
- Check container logs (including logs from previous containers):
bash
kubectl logs <pod-name> [-c <container-name>]# View current container logs
kubectl logs <pod-name> –previous # View logs from the last terminated container
- Enter the container for debugging (if there is a shell inside the container):
bash
kubectl exec -it <pod-name> — /bin/sh
You can try manually accessing the health check endpoint (curl http://localhost:<port>/<path>) to verify if the application is truly healthy.
Correctly configuring the HTTP GET Liveness Probe can significantly enhance the resilience and self-healing capabilities of applications in Kubernetes. We hope the above information is helpful to everyone.
#httpgetlivenessprobe#kubernetes#containerlivenessprobe