Kubernetes liveness probes are a powerful feature that allows you to maintain the health of your applications running in a Kubernetes cluster. They help ensure that an application is properly functioning and can automatically restart containers if they are not responding or functioning as expected. Understanding how liveness probes interact with your application is crucial for setting up a robust and resilient application.

What are Kubernetes Liveness Probes?

Kubernetes liveness probes are diagnostics performed by the kubelet (the primary node agent in Kubernetes) on a container. These probes help determine if the container is still alive and running as expected. If a probe fails, Kubernetes can take corrective actions, such as restarting the container, to bring the application back to its desired state.

Types of Liveness Probes

Kubernetes provides different types of liveness probes, each suited for specific scenarios:

1. HTTP Probes: They send HTTP GET requests to the container. If the response code is between 200 and 399, the container is considered healthy.
2. TCP Socket Probes: They establish a TCP connection. If the socket connection is successful, the container is healthy.
3. Exec Probes: They run a specified command inside the container. If the command returns a zero exit code, the container is considered healthy.

These different probes cater to various needs, allowing you to choose the probe that best fits your application's architecture and behavior.

Do Liveness Probes Run in Parallel with the Application?

Yes, liveness probes run in parallel with your Kubernetes application. This parallel execution is crucial as it ensures that regular health checks do not block the application's normal operations.

Parallel Execution Explained

When a liveness probe is configured, the kubelet schedules and runs the probe independently of the container's main processes. It is designed to check the health of an application and not its performance characteristics directly. This means that while your application runs its normal workload, the kubelet continuously checks the probe to ascertain the health status of the application.

For instance, consider an HTTP liveness probe configured to hit the `/healthz` endpoint every 15 seconds. Your application will handle this probe request alongside other user requests or workloads it is processing. This design ensures minimal disruption while maintaining operational efficiency.

Configuring Liveness Probes

Setting up a liveness probe requires adding specific keys in your Pod's configuration YAML. The example below showcases a basic configuration:

• name: myapp
• Detecting Application Crashes: Restart a container when the application crashes or becomes unresponsive.
• Maintaining Desired State: Automatically correct deviations from the application's desired state.
• Service Availability: Ensure critical services are always available by promptly identifying and rectifying failures.
• Define a separate endpoint or lightweight check for probes to avoid overload.
• Adjust `initialDelaySeconds` and `periodSeconds` based on startup times and application requirements.
• Use multiple types of probes (HTTP, TCP, Exec) if necessary to cover more ground in health diagnostics.