Kubernetes Probes

A Kubernetes probe is a health check that tells the kubelet whether a container is alive, healthy, and ready to receive traffic.

Probes help Kubernetes decide when to restart a container, when to route traffic to it, and whether it is healthy.

The kubelet is the node agent that runs inside each node and manages the containers in Pods.

The container lifecycle includes startup, running, readiness, and termination.

A readiness probe checks whether a container is ready to accept traffic.

A liveness probe checks whether a container is alive and should be restarted if it is unhealthy.

A startup probe checks whether the application has completed startup before liveness and readiness checks begin.

They prevent traffic from reaching containers that are not yet ready.

They allow Kubernetes to restart containers that have become stuck or unhealthy.

They help slow-starting applications avoid being restarted prematurely by liveness probes.

A probe action is how Kubernetes checks health, such as HTTP, TCP, or command execution.

An HTTP probe sends an HTTP request to a specific path and expects a status code response.

A TCP probe checks whether a port is open and accepting connections.

An exec probe runs a command inside the container and succeeds or fails based on exit code.

The threshold is the number of consecutive failures before a probe is considered failed.

The period is how often the kubelet runs the probe.

The timeout is how long the probe waits before considering the check failed.

Initial delay is how long the kubelet waits before starting the first probe.

Failure threshold is how many consecutive failures are required before a probe transitions to failure.

Success threshold is how many consecutive successful checks are required before a probe is considered successful again.

Because Services only route traffic to ready Pods.

A Pod condition reflects the current state of readiness, liveness, or startup.

A Pod is marked ready when all readiness probes pass and the pod is ready to receive traffic.

It means Kubernetes will not send traffic to it via a Service unless special routing rules apply.

The container is restarted by the kubelet unless the container is not restartable.

A liveness probe that is too aggressive can restart healthy containers unnecessarily.

In an HTTP probe, the target path is the URL path to request, such as /healthz or /ready.

The probe port is the port the kubelet uses to connect for HTTP or TCP probes.

These are conventional endpoints often implemented by apps to report internal health.

App health is whether the application is functioning correctly and able to serve traffic.

A process health check checks whether the main process is alive and responding.

A dependency check verifies that an app can reach required databases, caches, or other services.

If the app cannot reach a database, it may not be ready even though the process is running.

It ensures the app has enough time to initialize before liveness begins.

Because their initialization can take minutes, and liveness would otherwise restart them.

Example:

• readinessProbe: HTTP GET on /ready
• livenessProbe: TCP port 8080
• startupProbe: HTTP GET on /startup

A rapid restart loop occurs when a container keeps failing health checks and being restarted.

It can create instability and hide the underlying problem.

A production probe is a health check designed for live traffic and operational reliability.

Because a probe may test the wrong thing or use logic that doesn’t reflect actual readiness.

A false positive means the probe says healthy when the application is actually broken.

A false negative means the probe says unhealthy when the application is actually working.

Because they affect traffic routing and restarts.

A health endpoint is an HTTP URL that returns status to indicate app health.

A readiness endpoint indicates the application is ready to accept real traffic.

A liveness endpoint indicates the process is alive, even if it is not ready for traffic.

Because being alive is not the same as being ready to serve requests.

An app whose startup takes longer than a few seconds and needs delayed liveness checks.

A long-running job may not be a web service and may not need normal readiness semantics.

An init container runs before app containers start and can perform setup or dependency checks.

They can do one-time setup before the main app starts.

Readiness gating prevents traffic from reaching a pod until it is ready.

It means the app has passed readiness checks and is included in Service endpoints.

It may test DB connectivity, cache connectivity, or external service availability.

A probe may expect 200-399 as success, and other codes as failure.

It only checks socket availability, not application correctness.

Because the app could accept connections but still fail deeper logic or user requests.

It runs a shell command inside the container and expects a zero exit code.

They use shell execution inside the container, which adds complexity and performance overhead.

It is the periodic sequence in which the kubelet runs configured probes.

It is the sequential execution of health checks on the node.

It is the moment a container transitions through startup, ready, and alive states according to checks.

Readiness controls if traffic is routed to the pod. Liveness controls if the pod should be restarted.

Probes add small overhead but generally are lightweight compared with the application itself.

Because a misconfigured or heavy probe can affect node performance.

A 503 often indicates the app is not ready or not healthy.

It clearly signals the app is ready.

It may be a lightweight health response with no payload.

Failure tolerance describes how many probe failures are allowed before the app is considered dead or unready.

This can happen if the app waits on a dependency or a bad startup path.

Because the app may be failing the liveness probe repeatedly even though it is not truly stuck.

This is often used when the app takes a while to start, but should be handled gracefully.

It indicates the pod is not included in Service endpoints because readiness checks are failing.

It means the probe is checking the app is accepting requests.

It is an HTTP probe in Kubernetes manifest syntax.

It is a TCP socket probe in Kubernetes manifest syntax.

It is a command-based probe in Kubernetes manifest syntax.

It denotes which container port is used for the probe.

Host is not commonly used for probes, but some special wiring may target host-level addresses in advanced scenarios.

The scheme selects HTTP or HTTPS for the probe request.

How long the kubelet waits before performing the first probe check.

How often the probe runs.

How long the probe waits before considering the check failed.

The number of consecutive failures before the kubelet marks it unhealthy or unready.

The number of successes required before a failed probe becomes successful.

Because the kind of probe and thresholds determine traffic behavior and restarts.

It can work but often misses application-level problems like database unavailability.

Because the app may be alive but still unable to serve user traffic.

A container that exits quickly may not be caught by readiness or liveness if the process dies.

A crash loop is when a container repeatedly exits and restarts, often due to a failure.

Restart policy determines whether Kubernetes restarts the container after failure.

Because restart policy defines what happens when the container fails.

When the app fails liveness, kubelet restarts the container.

A Pod phase includes Pending, Running, Succeeded, Failed, and Unknown.

A Pod can be Running but not Ready.

Running means the process exists. Ready means traffic can be routed to it.

This is the core function of readiness in Kubernetes Services.

Ingress traffic is routed through Services to ready Pods.

Because external systems often rely on the Service and Ingress to route to the correct Pods.

To ensure the app is alive, ready, and actually able to serve traffic.

Readiness is about traffic eligibility. Startup is about not treating a still-starting app as failed too early.

Because liveness could restart the process before it finishes initialization.

It may check that required databases or caches are reachable before the app becomes ready.

It checks that the app can connect to the DB before accepting requests.

It verifies the app can reach required external services or APIs.

It might return 503 if DB connectivity is broken even though the app process is running.

It is often enough for CPU-bound processes that either run or not.

Network or dependency outages may not be the app’s fault but can make it appear unhealthy.

A startupProbe can give the app enough time before liveness becomes active.

Because /healthz often means “process alive”; /ready means “can serve traffic”.

Apps can return JSON or plain text describing health to help debugging.

Because they are called frequently by kubelet and should not be expensive.

It can combine DB ping, cache ping, and response readiness checks.

Because they may become expensive or cause cascading failures if dependencies are slow.

A shallow readiness check confirms the process is ready to accept traffic without doing deep dependencies.

A deep readiness check validates the app can talk to critical dependencies and is fully functional.

Because a pod should only receive traffic when the app is truly usable.

A liveness probe can detect this by failing repeatedly and restarting the container.

Because the process may appear alive but is hung.

This is a common pattern for apps exposing management or health endpoints locally.

The kubelet updates pod readiness, which then updates Service endpoints.

It influences inclusion in Service endpoints and external routing.

The pod is not ready until readiness checks pass.

The app might look ready but not actually be able to serve all traffic.

The app might be healthy but kept out of Service traffic due to a probe bug.

Many health checks treat 2xx as success.

Some apps intentionally use 503 or 500 to signal not ready.

Because it tells the kubelet and the load balancer that the app is not ready for traffic.

It checks if the port accepts a TCP connection.

Because it says “port is open,” not “app is healthy”.

It executes `curl` inside the container and fails the probe if the HTTP call is not successful.

Because HTTP semantics map well to app health and readiness.

Because they are heavier and more complex to manage within containers.

It is an exec-based check for a file signifying health.

For some applications, a health file or lock file indicates whether to continue serving.

Because the container may need time to warm caches or connect to external services.

Because startup time varies across deployments and frameworks.

Example pattern:

• startupProbe: httpGet /startup
• livenessProbe: httpGet /healthz
• readinessProbe: httpGet /ready

Startup must start first, then readiness/liveness become active after startup completes.

Because a slow app may fail the liveness probe before it has fully initialized.

Once a failure threshold is reached, kubelet marks the container unhealthy or unready.

A readiness probe may show failures during teardown to stop new traffic before shutdown.

It is a direct signal of whether production traffic should be routed to a pod.

• using liveness as readiness
• no probes at all
• overly aggressive thresholds
• testing the wrong dependency
• using heavy checks in every loop

Because a pod can be alive but not able to serve traffic; restarting it is not always the solution.

Because it can check a narrower set of conditions than /healthz.

Because it can check just whether the process is alive and not in a hung or broken state.

It can confirm the app finished initialization, such as migrations or warm-up.

Ingress and service routing rely on readiness to avoid sending traffic to unready pods.

It means a pod is running but not receiving traffic because readiness checks fail.

Because it is effectively removed from the routing pool even though the process may still be alive.

This is often used for a very simple probe.

Many frameworks expose /health, /healthz, /actuator/health, /ready, or equivalent.

Because a probe endpoint must be supported by the application logic.

Ready pods receive traffic; unready ones are removed from endpoints while new versions roll out.

Because the Service should route only to stable and ready versions.

The rollout strategy uses readiness to decide when a new pod is eligible for traffic.

Because kubelet events and pod conditions reveal why a pod isn’t ready or keeps restarting.

Because they indicate bottlenecks or configuration mistakes in the application lifecycle.

It records readiness transitions, deaths, restarts, and liveness failures.

Example: `["/bin/sh", "-c", "curl -f http://localhost:8080/ready || exit 1"]`

HTTP probes are usually the most readable and maintainable for web services.

Because it says the port is reachable, not that the application is fully ready to respond.

Because startup often includes initialization work while readiness indicates actual service availability.

It could be an actuator health check or a custom endpoint.

The kubelet may emit warnings or events describing failed readiness or liveness.

They inspect them while debugging restarts or unready pods.

It can generate excessive checks and load on the app or node.

It delays detection of failure or readiness changes.

Use modest intervals, clear paths, and a meaningful readiness condition aligned to app behavior.

Because readiness determines business traffic routing and user impact.

It might wait until migrations are complete before readiness becomes true.

It waits until the cache is warmed before allowing traffic.

It waits until TLS certificates and keys are loaded before becoming ready.

It waits until required external services are reachable before the service accepts traffic.

Because some apps need both time to initialize and a precise signal that the app can handle requests.

That is usually a sign the app is not ready yet or the dependency is still failing.

Because readiness is user-service oriented while liveness is process health oriented.

Service endpoints are updated based on readiness. Unready pods are removed from traffic.

Because traffic routing is only as good as the readiness and liveness signals.

It becomes the ongoing signal that the process is still alive and functioning.

Because Java apps may take time to start, and liveness should not kill them too early.

A startup probe usually runs until success and then liveness and readiness checks become active.

Probe gating means the kubelet only checks the readiness and liveness signals at the appropriate lifecycle stage.

It usually indicates the app remains broken or is taking too long to initialize.

Because a process can be alive while dysfunctional.

It is the contract between app and platform: e.g. "200 means healthy and ready, 503 means not ready".

It gives operators and developers a clear signal for infrastructure behavior.

Tighter probes detect issues faster but can create noise and false positives; slower probes are less noisy but delay detection.

It balances how many failures are tolerated before making the container unhealthy or unready.

It defines how much evidence is needed before a previously failing probe is considered healthy again.

Because readiness may recover more quickly while liveness may need a stronger signal before restart.

It may check a critical dependency such as a database or message broker.

Because checking every downstream dependency may make readiness too sensitive or too expensive.

It can ensure the app has established necessary connections before being routed.

Because it reflects how the platform expects the application to behave under failure.

It can lead to pods being marked unready or restarted unexpectedly, causing outage or flapping.

Flapping is when a pod repeatedly transitions between healthy and unhealthy states.

It causes unstable traffic routing and complicates investigations.

Probes are the operational contract between Kubernetes and the application: they define health, readiness, and recovery behavior, and they must reflect real service semantics to avoid outages and premature restarts.