Readiness Probe

The primary function is to gate traffic. A pod passes its readiness probe only when all its containers are fully operational, including completed dependency initialization (e.g., database connections, cache warming, large model loading). Until then, the pod's IP address is removed from the Service's Endpoints list, preventing the kube-proxy or Ingress controller from routing requests to it. This prevents user requests from hitting a partially started application, which is critical for stateful services and agents loading large context.

Kubernetes supports three mechanisms for executing the check:

• HTTP GET Probe: Sends an HTTP request to a specified path and port. Success is defined by a response status code between 200 and 399. This is the most common type for web services and APIs.
• TCP Socket Probe: Attempts to open a TCP connection to a specified port. Success is defined by the connection being established. Used for non-HTTP services like databases or custom gRPC servers.
• Exec Probe: Executes a specified command inside the container. Success is defined by a zero exit code. Used for complex, application-specific startup logic that cannot be expressed as a simple HTTP or TCP check.

Probe behavior is finely tuned via parameters in the container spec:

• initialDelaySeconds: Wait time after container start before initiating probes. Crucial for applications with long boot sequences.
• periodSeconds: How often (in seconds) to perform the probe.
• timeoutSeconds: Number of seconds after which the probe times out.
• successThreshold: Minimum consecutive successes for the probe to be considered passed after failing.
• failureThreshold: Number of consecutive failures required for the probe to be considered failed. After this, the pod is marked 'Not Ready'.

In a service mesh like Istio or Linkerd, the readiness probe interacts with the sidecar proxy. The probe must succeed for both the application container and the sidecar proxy container for the pod to receive traffic. This ensures the proxy's routing tables and mTLS connections are fully initialized. Misconfiguration here is a common cause of traffic drops during deployments, where the app starts but the proxy is not ready to route.

Readiness vs. Liveness: A failed liveness probe causes the container to be restarted. A failed readiness probe only removes the pod from service endpoints. Use liveness to catch deadlocks; use readiness for temporary unavailability. Readiness vs. Startup: A startup probe is used for legacy applications with extremely slow startup times. It disables liveness and readiness checks until it succeeds once, after which the readiness probe takes over for the remainder of the container's lifecycle.

Readiness probes are foundational for safe rolling updates, canary deployments, and blue-green deployments. During a rolling update, Kubernetes waits for new pods to pass their readiness probes before terminating old ones, ensuring continuous service availability. For a canary, a new version pod is created; only after its readiness probe passes is it added to the pool to receive a percentage of live traffic, enabling performance validation without impacting all users.

A periodic check that determines if a containerized application process is still running and responsive. Unlike a readiness probe, which checks if an app is ready for work, a liveness probe checks if it is alive. If it fails, the container orchestrator (e.g., Kubernetes) will typically restart the container to attempt recovery. This is crucial for recovering from deadlocks or other runtime hangs.

• Purpose: Detect and recover from process crashes.
• Common Checks: HTTP endpoint response, TCP socket connection, or command execution success.
• Key Difference: A failed liveness probe triggers a restart; a failed readiness probe only removes the pod from service load balancers.

A generic term for any automated mechanism used to assess the operational status of a software component. In cloud-native contexts, it encompasses liveness, readiness, and startup probes. For agentic systems, health checks can be extended to monitor internal reasoning loops or tool availability.

• Broad Category: Includes endpoint pings, dependency checks, and custom logic.
• Orchestrator Action: Results dictate lifecycle management (restart, route traffic, delay).
• Agentic Context: May involve checking the responsiveness of a vector database connection or a critical external API that the agent depends on.

A specialized health check used for applications with lengthy initialization periods, such as legacy monoliths or agents loading large knowledge graphs. It activates at container start and, upon success, enables the standard liveness and readiness probes. This prevents the orchestrator from killing a slow-starting container before it's fully up.

• Use Case: Applications that take minutes to initialize caches or connect to numerous dependencies.
• Configuration: Typically has a higher failureThreshold and periodSeconds than other probes.
• Lifecycle: Disabled after first success, handing off to liveness/readiness monitoring.

The process by which an application, upon receiving a termination signal (e.g., SIGTERM), completes its in-flight requests and releases resources before exiting. This is coordinated with a readiness probe, as the pod is removed from service endpoints early in the shutdown sequence to prevent new traffic.

• Mechanism: Uses the container lifecycle preStop hook to begin a shutdown procedure.
• Interaction with Probes: The readiness probe should start failing once shutdown is initiated, signaling the service mesh to stop routing new requests.
• Importance: Prevents data corruption and ensures a positive user experience during deployments and scaling events.

A dedicated infrastructure layer that manages service-to-service communication within a cluster, using sidecar proxies (e.g., Istio's Envoy). It provides advanced traffic management, security, and—critically—observability. A service mesh uses the results of readiness and liveness probes to make intelligent routing and failover decisions.

• Traffic Management: Enables canary deployments, A/B testing, and circuit breaking.
• Health Integration: Proxies consume health check statuses to update load balancer pools in real-time.
• Agentic Systems: Can manage and secure communication between different agents and their tooling endpoints.

A deployment strategy where new versions of an application are gradually rolled out by replacing old pods with new ones. Readiness probes are fundamental to this process. The orchestrator waits for a new pod to pass its readiness probe before scaling down an old one, and will halt the rollout if too many new pods fail.

• Zero-Downtime: Achieved by ensuring at least some replicas are always ready to serve traffic.
• Probe Dependency: The maxUnavailable and maxSurge parameters directly interact with readiness probe results.
• Rollback Automation: If the new version's pods consistently fail readiness checks, the update can be automatically rolled back to the previous stable version.