🔍 What Are Probes?
Probes help Kubernetes monitor the health and availability of your containers.
| Probe Type | Purpose |
|---|---|
livenessProbe | Checks if the container is alive (running). Restart if it fails. |
readinessProbe | Checks if the container is ready to serve traffic. Remove from service if it fails. |
startupProbe | Used when app takes time to start up. Replaces liveness check during startup phase. |
⚙️ How They Work
-
Kubernetes runs the probe periodically.
-
If it fails:
- Liveness: Container is restarted.
- Readiness: Removed from Service endpoints.
- Startup: If it fails during startup, container is killed and restarted.
-
You can probe via:
httpGettcpSocketexec
📦 Liveness, Readiness, Startup Probe - All in One Example
apiVersion: v1
kind: Pod
metadata:
name: probe-example
spec:
containers:
- name: my-app
image: myapp:1.0
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 3
startupProbe:
httpGet:
path: /startup
port: 8080
failureThreshold: 30
periodSeconds: 5📘 Explanation
| Probe | What It Checks | Outcome |
|---|---|---|
| Liveness | Is the app still running? (e.g., /healthz) | Restarts container if it stops responding |
| Readiness | Is it ready to serve traffic? (e.g., /ready) | Traffic is sent only if this passes |
| Startup | Is the app still starting? (e.g., /startup) | Waits longer before liveness checks begin |
🛠️ Common Real-Life Use Cases
🧠 1. Web App with /health, /ready, /startup Endpoints
livenessProbe:
httpGet:
path: /health
port: 8080
readinessProbe:
httpGet:
path: /ready
port: 8080
startupProbe:
httpGet:
path: /startup
port: 8080- Useful for apps like Django, Spring Boot, Laravel, etc.
/startupmight return 503 until database is connected./readyonly after cache is warmed.
🧠 2. App That Listens on a Port (TCP Probe)
livenessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 10
periodSeconds: 10✅ Ideal for:
- Databases (MySQL, PostgreSQL)
- Services with raw socket listening
🧠 3. Use exec to Check Disk or Service
readinessProbe:
exec:
command:
- cat
- /tmp/ready✅ Example: Readiness is indicated by the presence of a file /tmp/ready.
Can be used when:
- No HTTP endpoint is available
- Internal logic can mark file-based readiness
🚦 Visual Flow: Probe Behavior
+-------------+
| Container |
+-------------+
|
+-------------+--------------+
| |
+-----v-----+ +-------v-------+
| Liveness | | Readiness |
+-----+-----+ +-------+-------+
| |
Restart if fails Remove from Service if fails
+------------------+
| Startup Probe |
+--------+---------+
|
(If defined, delays liveness check)⏱️ Common Configuration Parameters
| Parameter | Meaning |
|---|---|
initialDelaySeconds | Time to wait before first probe (useful for cold start apps) |
periodSeconds | How often to run the probe |
timeoutSeconds | How long to wait for the probe response |
failureThreshold | Number of failures before marking container as failed |
successThreshold | Number of successes to mark container as healthy (readiness only) |
✅ Best Practices
| Practice | Why |
|---|---|
Use startupProbe for slow-starting apps | Prevent premature liveness kill |
| Use HTTP probes with framework health endpoints | Integrates well with /health and /ready |
Keep timeoutSeconds low for quick response | Prevent resource hang |
Don’t use livenessProbe for debugging | It restarts your container |
Use readinessProbe to control load balancer traffic | Ensures app is ready |
💬 Summary Table
| Probe Type | Use When… | Action Taken |
|---|---|---|
| Liveness | App might hang or crash | Kills & restarts the pod |
| Readiness | App needs time to warm up or become healthy | Temporarily removes from service |
| Startup | App has slow init (e.g., database, cache) | Waits longer before applying liveness |