Liveness Probe

The most common liveness probe type, which sends an HTTP GET request to a specified path and port on the container. The probe is considered successful if the server returns a response with an HTTP status code between 200 and 399.

• Use Case: Ideal for web servers, REST APIs, and any service with an HTTP endpoint dedicated to health.
• Configuration: Requires specifying path, port, and optionally httpHeaders.
• Example: A probe checking http://localhost:8080/healthz. A 200 OK means the app is alive; a 404 or 500 triggers a restart.

A probe that attempts to open a TCP connection to a specified port on the container. Success is based solely on whether a TCP handshake can be established; no data is sent or received.

• Use Case: Best for non-HTTP services like databases (PostgreSQL, Redis), custom TCP protocols, or gRPC services (where a simple port check suffices).
• Configuration: Requires only the port number.
• Key Consideration: It only confirms the port is listening, not that the service is functionally healthy. A deeper health check may require a different probe type.

A probe that executes a specified command inside the container. The probe is successful if the command exits with a status code of 0; any other exit code indicates failure.

• Use Case: For complex health checks that require custom logic, such as checking the state of a file, verifying internal process status, or running a diagnostic script.
• Configuration: Defined by a command array in the pod spec.
• Example: A command like ["pg_isready", "-U", "postgres"] to check PostgreSQL readiness. Caution: Exec probes consume more resources than HTTP/TCP probes and the command must be present in the container's filesystem.

Beyond the type, liveness probes are governed by critical timing parameters that control their behavior and aggressiveness:

• initialDelaySeconds: Wait time after container starts before probes begin. Crucial for apps with slow startup.
• periodSeconds: How often to perform the probe (e.g., every 10 seconds).
• timeoutSeconds: Time after which the probe is considered failed if no response.
• successThreshold: Consecutive successes required to mark a failed container as healthy (defaults to 1 for liveness).
• failureThreshold: Number of consecutive failures before the container is considered unhealthy and is restarted.

Misconfiguring these values is a common cause of unnecessary pod restarts or unresponsive containers.

Liveness probes are one of three health check types in Kubernetes, each with a distinct purpose:

• Liveness Probe: Answers "Is the container alive?" Failure results in a container restart.
• Readiness Probe: Answers "Is the container ready to serve traffic?" Failure removes the pod from service load balancers but does not restart it. Used for temporary unavailability (e.g., loading large cache).
• Startup Probe: Answers "Has the application finished starting up?" Disables liveness/readiness checks until it succeeds once. Designed for legacy apps with lengthy, unpredictable startup times.

A robust deployment often uses a combination: a startup probe for initialization, then readiness for traffic management, and liveness as a last-resort restart mechanism.

Defines the method used to check the container's liveness. The three primary types are:

• HTTP GET Probe: Sends an HTTP request to a specified path and port. A successful response (HTTP status code between 200 and 399) indicates the container is alive.
• TCP Socket Probe: Attempts to open a TCP connection to a specified port. Success on connection establishes liveness.
• Exec Probe: Executes a specified command inside the container. A zero exit code from the command indicates success. The choice depends on the application's architecture; a web service typically uses an HTTP GET probe, while a database might use a TCP socket probe.

The number of seconds to wait after the container starts before initiating the first liveness probe. This is a critical parameter for applications with slow initialization times (e.g., legacy monoliths, JVM-based services). Setting this too low will cause the orchestrator to kill the container before it has finished starting up, leading to a restart loop. A best practice is to set this value slightly higher than the worst-case startup time observed during testing.

Specifies how often (in seconds) to perform the liveness probe after the initial delay. This defines the check frequency. A common default is 10 seconds. A shorter period detects failures more quickly but increases overhead. A longer period reduces overhead but allows an unhealthy container to serve traffic for a longer duration. The value should balance responsiveness with system load.

The number of seconds after which the probe times out. If the probe does not complete within this window, it is recorded as a failure. This must be set lower than the periodSeconds. For HTTP GET probes, this is the maximum time to wait for an HTTP response. A timeout typically indicates the application is hung or severely degraded, not just slow.

These parameters introduce hysteresis, preventing flapping due to transient issues.

• Success Threshold: The minimum number of consecutive successful probes required for a container that has previously failed to be considered healthy again. This is typically 1.
• Failure Threshold: The number of consecutive probe failures required for the container to be considered unhealthy. A value greater than 1 (e.g., 3) allows the container to survive transient network glitches or brief garbage collection pauses without being restarted.

The endpoint or command targeted by the probe must be carefully designed. It should:

• Perform a minimal, internal-state check (e.g., check a local cache, verify a thread pool is responsive).
• Avoid complex logic or calls to downstream dependencies (databases, external APIs), as their failure does not necessarily mean the container itself is dead.
• Be idempotent and have no side effects. A liveness probe should not change application state or trigger business logic. A poorly designed endpoint can lead to false positives and unnecessary restarts.

A Kubernetes health check that determines if a container is fully initialized and ready to accept network traffic. Unlike a liveness probe, which restarts a non-responsive container, a failed readiness probe removes the pod's IP address from the service's endpoint list, stopping new traffic from being routed to it.

• Purpose: Signal that the application has completed its startup sequence (e.g., loaded caches, opened database connections).
• Failure Consequence: The pod is marked as "Not Ready" and is taken out of the load balancer pool.
• Typical Commands: HTTP GET on a /ready endpoint, TCP socket check, or execution of a custom command script.

A Kubernetes health check used for legacy applications or services with exceptionally long startup times. It disables the activity of liveness and readiness probes until the startup probe succeeds, preventing the orchestrator from killing the container before it has had a chance to fully start.

• Purpose: Protect slow-starting containers from being restarted prematurely.
• Failure Consequence: The container is killed and restarted according to its restart policy.
• Use Case: Java applications with large heaps, monolithic legacy systems initializing many components.

A periodic diagnostic test performed by an orchestrator or monitoring system to verify an application instance is functioning correctly. In Kubernetes, this is implemented via the three probe types (liveness, readiness, startup). In broader cloud-native architectures, health checks are used by load balancers and service meshes to determine instance viability.

• Core Mechanism: Active polling or passive analysis of application state.
• Key Attributes: Check interval, timeout period, success/failure thresholds.
• Broader Context: Part of the Service Level Indicator (SLI) definition for system availability.

The orderly termination process for an application, allowing it to complete in-flight requests, release resources, and persist state before the container runtime forces it to stop. This is often coordinated with a PreStop lifecycle hook in Kubernetes, which sends a SIGTERM signal, giving the application a configurable period to shut down before a SIGKILL.

• Contrast with Liveness: Liveness ensures the app is alive; graceful shutdown ensures it dies cleanly.
• Importance for Agents: Critical for agent state monitoring to prevent data loss or corruption when pods are rescheduled.
• Kubernetes Hook: lifecycle.preStop

A resiliency pattern that prevents an application from repeatedly attempting to call a failing service. If failures exceed a threshold, the circuit "opens," and requests fail fast for a period, allowing the downstream service time to recover. This is a complementary pattern to health checks.

• Relation to Probes: While a liveness probe restarts a local container, a circuit breaker protects your service from remote failures.
• Implementation: Common in service meshes (e.g., Istio) and client libraries (e.g., Resilience4j).
• States: Closed (normal operation), Open (failing fast), Half-Open (testing for recovery).

A Kubernetes policy that limits the number of concurrent voluntary disruptions to pods belonging to an application, ensuring high availability during cluster maintenance operations like node drains or updates. It works in concert with liveness probes to maintain application quorum.

• Voluntary vs. Involuntary: PDBs govern voluntary disruptions (user-initiated). Liveness probe failures cause involuntary disruptions.
• Key Parameters: minAvailable or maxUnavailable pods.
• Use Case for Agents: Ensures a minimum number of autonomous agent replicas remain running during cluster operations, preserving system capability.