CKA Day 18 — Kubernetes Health Probes Explained: Liveness vs Readiness Probes

CKA Day 18 — Kubernetes Health Probes Explained

Day 18 of the 40-day CKA course by Tech Tutorials with Piyush.

Core Synthesis

This lesson introduces the three Kubernetes health probe mechanisms — Liveness, Readiness, and Startup — that keep production workloads healthy by enabling the kubelet to make intelligent decisions about container lifecycle and traffic routing.

Why Probes Matter

Without probes, Kubernetes treats a container as “healthy” the moment its main process starts. In reality, an application may need seconds or minutes to warm up caches, connect to databases, or load configuration. Worse, a running process can enter a degraded state (infinite loop, deadlock, memory leak) without crashing — leaving it alive but useless. Probes solve both problems.

The Three Probe Types

Probe	Purpose	Action on Failure
Liveness	Is the container alive? Should it be restarted?	kubelet kills and restarts the container
Readiness	Is the container ready to accept traffic?	kubelet removes Pod IP from Service Endpoints
Startup	Has a slow-starting container finished initializing?	Disables liveness/readiness checks until it succeeds, preventing premature restarts

Critical distinction: Liveness affects the container (restart it), Readiness affects the Service (stop sending traffic). Confusing the two is a common production incident pattern.

Probe Mechanisms (How to Check)

Kubernetes supports four ways to probe a container:

Mechanism	How It Works	Best For
HTTP GET	Sends an HTTP request to a specific path/port	Web apps, REST APIs, health-check endpoints (/healthz)
TCP Socket	Attempts to open a TCP connection to a port	Databases, caches, message queues, gRPC services
Exec	Runs a command inside the container; exit code 0 = success	Custom scripts, file-existence checks, complex validation
gRPC	Native gRPC health-checking protocol (Kubernetes 1.27+, alpha)	gRPC-first microservices

Key Parameters

Every probe shares these timing knobs:

Parameter	Default	Purpose
initialDelaySeconds	0	Wait this long after container start before first probe
periodSeconds	10	How often to run the probe
timeoutSeconds	1	How long to wait for a probe response before counting it as failed
successThreshold	1	Consecutive successes needed to mark healthy
failureThreshold	3	Consecutive failures needed to mark unhealthy and trigger action

Exam Trap: failureThreshold: 3 with periodSeconds: 10 means a container is declared unhealthy after 30 seconds of failures — not 10. Many candidates miss this on timing questions.

Liveness Probe in Practice

A liveness probe catches deadlocks and infinite loops that do not crash the process. Example: an HTTP server that responds on /healthz but has locked its main thread.

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

When this probe fails 3 times in a row, the kubelet restarts the container. The Pod stays on the same node; only the container is recreated. This is self-healing at the container level.

Readiness Probe in Practice

A readiness probe ensures traffic only hits Pods that are truly ready. Example: an app that must connect to a database before serving requests.

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

When readiness fails, the Pod’s IP is removed from the Service’s Endpoints object. Existing connections are not killed, but new requests stop routing to this Pod. Once readiness succeeds again, the IP is re-added automatically.

Startup Probe in Practice

The startup probe was added in Kubernetes 1.16 to protect slow-starting containers from aggressive liveness checks. Without it, a large Java or ML model container might get killed by liveness before it finishes initializing.

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

This gives the container 5 minutes (30 × 10s) to start. While the startup probe is running, liveness and readiness probes are disabled. After startup succeeds, the other probes begin.

Integration with Services and Deployments

Probes do not exist in isolation. They interact with the broader Kubernetes control loop:

1. kubelet runs the probes on each node
2. kubelet reports Pod status to the API Server
3. EndpointSlice controller watches Pod readiness and updates EndpointSlices
4. kube-proxy reads EndpointSlices and programs iptables/ipvs rules
5. Deployment controller counts available replicas using readiness; rolling updates wait for new Pods to become ready before terminating old ones

Common Production Patterns

Pattern	Description
Separate endpoints	Use /healthz for liveness and /ready for readiness. They often check different things (liveness = “not deadlocked”, readiness = “DB connected”).
Startup + Liveness	Always pair a startup probe with a liveness probe for slow-starting containers.
Exec for legacy apps	When the app has no HTTP server, use an exec probe that checks a PID file or socket.
TCP for stateful services	Redis, PostgreSQL, and Kafka often use TCP socket probes on their native ports.

CKA Exam Patterns

• Imperative creation does not support probes easily — you will write YAML manifests
• kubectl describe pod <name> shows probe failures under Events
• If a Pod is Running but not receiving traffic, check readiness first
• If a Pod restarts repeatedly, check liveness thresholds and initialDelaySeconds
• kubectl get endpoints <svc> shows whether readiness is filtering Pods out of the Service

See Also

Wiki Concepts

• Kubernetes Health Probes — Deep-dive page with YAML anatomy, troubleshooting matrix, and CKA speed patterns
• Pod Fundamentals — The container unit that probes act upon
• Deployment, ReplicaSet & Replication Controller — Rolling updates depend on readiness probes
• Kubernetes Services — Readiness probes control EndpointSlice membership
• Kubernetes Architecture — How kubelet runs probes and reports to the API server
• Kubernetes Autoscaling — HPA counts ready replicas for scaling decisions
• Kubernetes Resource Requests and Limits — Probes and resource constraints together define Pod health
• CKA Certification — Exam structure where probes appear in Workloads and Troubleshooting domains
• CKA Study Roadmap — 40-day plan: Day 18 covers health probes

Related Sources

• CKA Day 17 — Kubernetes Autoscaling Explained: HPA vs VPA — Preceding day in the series
• CKA Day 16 — Kubernetes Requests and Limits — Resource scheduling context for probe timing

Creator / Entity

• Tech Tutorials with Piyush — Creator of the 40-day CKA course

---

Tags: cka kubernetes health-probes liveness readiness startup devops production