Cluster’ınız Bugün Çalışıyor, Peki Yarın? Kubernetes Probe Hakkında..

Why Probe Definitions Matter

Your cluster is safely handling production traffic today - but what about tomorrow?

As applications and infrastructure grow, Kubernetes increasingly depends on explicit health signals to make correct operational decisions. Probe definitions are one of the most important mechanisms that enable Kubernetes to understand the actual state of your applications.

Without probes, containers can become unresponsive while still appearing healthy, and traffic may be routed to applications that are not yet ready to serve requests.

The Three Types of Kubernetes Probes

Kubernetes provides three different probe types. Each answers a different operational question and serves a specific purpose.

Liveness Probe: Is the Container Still Alive?

A liveness probe determines whether the application is still functioning.

If the probe fails, Kubernetes assumes the container is unhealthy and restarts it.

Typical use cases include:

• Deadlocks

• Infinite loops

• Internal application freezes

Example

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

Readiness Probe: Can the Application Receive Traffic?

A readiness probe determines whether the application is currently capable of serving requests.

If the probe fails, Kubernetes removes the pod from Service endpoints but does not restart it.

Common scenarios include:

• Startup warm-up

• Cache loading

• Database connectivity issues

• Temporary overload

Example

readinessProbe:
  httpGet:
    path: /ready
    port: 8080

readinessProbe:
  httpGet:
    path: /ready
    port: 8080

readinessProbe:
  httpGet:
    path: /ready
    port: 8080

Startup Probe: Has the Application Finished Starting?

A startup probe protects applications that require a long initialization period.

Until the startup probe succeeds, liveness and readiness probes remain disabled.

This prevents Kubernetes from restarting applications that are simply taking longer than usual to start.

Typical examples:

• Spring Boot applications

• .NET services

• Large Python applications

Example

startupProbe:
  httpGet:
    path: /healthz
    port: 8080

startupProbe:
  httpGet:
    path: /healthz
    port: 8080

startupProbe:
  httpGet:
    path: /healthz
    port: 8080

How Probes Work Together

A typical pod lifecycle follows this sequence:

1. Container starts.

2. Startup probe begins running.

3. Startup probe succeeds.

4. Liveness and readiness probes become active.

5. Application enters normal runtime operation.

Together, these probes provide comprehensive health monitoring throughout the application lifecycle.

Probe Mechanisms

Kubernetes supports three different probe mechanisms.

HTTP GET Probes

The recommended approach for most web applications.

Kubernetes periodically calls an endpoint and expects an HTTP 200 response.

Example

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

TCP Socket Probes

Useful when no HTTP endpoint is available.

Kubernetes simply verifies that a TCP connection can be established.

Example

livenessProbe:
  tcpSocket:
    port: 5672

livenessProbe:
  tcpSocket:
    port: 5672

livenessProbe:
  tcpSocket:
    port: 5672

Exec Probes

Exec probes execute a command inside the container.

An exit code of 0 indicates success.

Example

livenessProbe:
  exec:
    command

livenessProbe:
  exec:
    command

livenessProbe:
  exec:
    command

Because a new process is created during each execution, exec probes can become resource-intensive when used frequently.

Best Practices for Kubernetes Probes

Use Different Endpoints for Liveness and Readiness

Liveness and readiness probes serve different purposes and should generally use separate endpoints.

Liveness Endpoint

The liveness endpoint should answer:

Is the application process alive?

It should focus only on the application's internal health.

Example

@app.get("/healthz")
def healthz():
    return {"status": "ok"}, 200

@app.get("/healthz")
def healthz():
    return {"status": "ok"}, 200

@app.get("/healthz")
def healthz():
    return {"status": "ok"}, 200

Readiness Endpoint

The readiness endpoint should answer:

Can this application safely handle traffic?

Dependency checks belong here.

Example

@app.get("/ready")
def ready():
    if not db.is_connected():
        return {"status": "db_down"}, 503

    if not cache.ping():
        return {"status": "cache_down"}, 503

    return {"status": "ready"}, 200

@app.get("/ready")
def ready():
    if not db.is_connected():
        return {"status": "db_down"}, 503

    if not cache.ping():
        return {"status": "cache_down"}, 503

    return {"status": "ready"}, 200

@app.get("/ready")
def ready():
    if not db.is_connected():
        return {"status": "db_down"}, 503

    if not cache.ping():
        return {"status": "cache_down"}, 503

    return {"status": "ready"}, 200

Use Startup Probes for Slow-Starting Applications

Applications with lengthy initialization phases should always use startup probes.

This prevents unnecessary restarts during startup and reduces the risk of CrashLoopBackOff events.

Example Configuration

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 30

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 2

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 30

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 2

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 30

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 2

Use Reasonable Timing Values

A good starting point for most workloads:

periodSeconds: 10
timeoutSeconds: 1
failureThreshold: 3

periodSeconds: 10
timeoutSeconds: 1
failureThreshold: 3

periodSeconds: 10
timeoutSeconds: 1
failureThreshold: 3

Liveness probes should generally be more tolerant than readiness probes because restarting a container is more disruptive than temporarily removing it from traffic.

Keep Health Endpoints Authentication-Free

Health endpoints should not require authentication.

Since Kubernetes does not provide authentication credentials when performing probe checks, protected endpoints will continuously fail.

Avoid Chained Readiness Checks

A service should report only its own health state.

Avoid creating dependencies such as:

Service A → Service B → Service C

Service A → Service B → Service C

Service A → Service B → Service C

This can create cascading failures across the system when a single downstream dependency becomes unavailable.

The Real Value of Probes Appears During Failures

The benefits of probes are often invisible when systems are operating normally.

However, during unexpected incidents, probes become a critical operational safeguard.

A deadlocked application at 3 AM can be automatically recovered by Kubernetes if proper probes are configured.

Without probes, the pod may continue appearing healthy while users experience service failures.

Conclusion

Kubernetes probes are much more than simple health checks.

When configured correctly, they:

• Detect application failures

• Prevent premature traffic routing

• Improve deployment reliability

• Enable automated recovery

• Reduce user-facing downtime

Probes act as an operational safety net for your cluster and are a fundamental part of running reliable production workloads.