==========================================================
CKA POD MASTERY
MODULE 4 - HEALTH PROBES (REVISION NOTES)
==========================================================
##########################################################
1. WHY DO WE NEED PROBES?
##########################################################
A container can be:
1. Starting
2. Running but not ready for traffic
3. Running and healthy
4. Running but hung/dead internally
Kubelet cannot determine all of these states by only checking if
the process exists.
Therefore Kubernetes provides three probes:
1. Startup Probe
2. Readiness Probe
3. Liveness Probe
----------------------------------------------------------
##########################################################
2. STARTUP PROBE
##########################################################
Purpose:
--------
Checks whether an application can successfully complete startup.
Question it answers:
--------------------
"Can this application finish starting?"
Used for:
---------
- Slow starting applications
- Spring Boot
- Java applications
- Applications loading cache
- Database initialization
How it works:
-------------
Container Starts
↓
Startup Probe runs
↓
If Fail
↓
Keep checking
↓
If Success (ONLY ONCE)
↓
Startup Probe is DISABLED forever
↓
Readiness and Liveness begin
Important:
----------
• Runs only during startup.
• Runs until first success.
• After success it never runs again for that container.
• If container restarts, Startup Probe starts again because it is a NEW container instance.
Configuration:
--------------
initialDelaySeconds
periodSeconds
failureThreshold
timeoutSeconds
Maximum startup time allowed:
initialDelaySeconds +
(periodSeconds × failureThreshold)
If startup never succeeds within this time:
→ Kubelet restarts container.
----------------------------------------------------------
##########################################################
3. READINESS PROBE
##########################################################
Purpose:
--------
Determines whether a Pod should receive traffic.
Question it answers:
--------------------
"Can I serve user requests?"
If Readiness succeeds:
Ready=True
↓
EndpointSlice Controller adds Pod IP
↓
kube-proxy updates iptables/IPVS
↓
Service sends traffic
If Readiness fails:
Ready=False
↓
EndpointSlice Controller removes Pod IP
↓
kube-proxy updates iptables/IPVS
↓
Service stops sending traffic
IMPORTANT:
----------
Readiness NEVER restarts a container.
Container continues running.
Only traffic is stopped.
----------------------------------------------------------
##########################################################
4. LIVENESS PROBE
##########################################################
Purpose:
--------
Determines whether the application is still healthy.
Question it answers:
--------------------
"Am I still alive?"
If Liveness succeeds:
Nothing happens.
Application keeps running.
If Liveness fails:
FailureThreshold reached
↓
Kubelet kills container
↓
RestartPolicy checked
↓
Container restarted
Repeated failures:
Restart
↓
Restart
↓
Restart
↓
Exponential Backoff
↓
CrashLoopBackOff
IMPORTANT:
----------
Liveness DOES restart containers.
----------------------------------------------------------
##########################################################
5. EXECUTION ORDER
##########################################################
Container Starts
│
▼
Startup Probe
│
▼
Startup Success
│
├─────────────┐
▼ ▼
Readiness Liveness
│ │
▼ ▼
Traffic Restart if unhealthy
----------------------------------------------------------
##########################################################
6. KUBELET RESPONSIBILITIES
##########################################################
Kubelet:
• Runs Startup Probe
• Runs Readiness Probe
• Runs Liveness Probe
• Updates Pod Ready condition
• Restarts failed containers
• Applies Restart Policy
----------------------------------------------------------
##########################################################
7. STARTUP vs READINESS vs LIVENESS
##########################################################
Startup Probe
Purpose:
Can application finish startup?
Controls:
Startup phase only
Restarts:
YES (if startup never succeeds)
Traffic:
NO
----------------------------------------------------------
Readiness Probe
Purpose:
Can application receive traffic?
Controls:
Traffic routing
Restarts:
NO
Traffic:
YES
----------------------------------------------------------
Liveness Probe
Purpose:
Is application still healthy?
Controls:
Container restart
Restarts:
YES
Traffic:
NO
----------------------------------------------------------
##########################################################
8. STARTUP PROBE vs LIVENESS initialDelaySeconds
##########################################################
Liveness initialDelaySeconds
Meaning:
"Wait X seconds.
After that I expect application to be healthy."
Problem:
If startup takes longer than expected,
container gets killed repeatedly.
----------------------------------------------------------
Startup Probe
Meaning:
"I don't know how long startup takes.
I'll keep checking until startup succeeds
or maximum startup time expires."
This removes the need to guess startup time.
----------------------------------------------------------
##########################################################
9. CRASHLOOPBACKOFF
##########################################################
CrashLoopBackOff is NOT a Pod phase.
It is kubectl STATUS shown when:
Container repeatedly exits
AND
RestartPolicy causes restart
AND
Kubelet applies exponential restart delay.
Typical delays:
Restart immediately
↓
10 sec
↓
20 sec
↓
40 sec
↓
80 sec
↓
160 sec
↓
300 sec (maximum backoff)
After maximum delay,
Kubelet still continues retrying approximately every 300 seconds
until the Pod is deleted or the problem is fixed.
----------------------------------------------------------
##########################################################
10. PROBE TIMELINE
##########################################################
Container Starts
│
▼
Startup Probe
│
├── Fail → Keep waiting
│
└── Success
│
▼
Startup Probe Disabled
│
▼
Readiness Starts
│
▼
Pod Ready=True
│
▼
Service sends traffic
│
▼
Application hangs
│
├───────────────┐
▼ ▼
Readiness Fail Liveness Fail
│ │
▼ ▼
Stop Traffic Restart Container
----------------------------------------------------------
##########################################################
11. IMPORTANT CKA POINTS
##########################################################
✓ Startup runs only until first success.
✓ Startup runs again after every container restart.
✓ Readiness controls traffic only.
✓ Readiness NEVER restarts containers.
✓ Liveness restarts unhealthy containers.
✓ Startup disables Readiness and Liveness until startup succeeds.
✓ EndpointSlice Controller reacts to Ready=True/False.
✓ kube-proxy updates iptables/IPVS after EndpointSlice changes.
✓ Services only send traffic to Ready Pods.
✓ CrashLoopBackOff is caused by repeated restarts with exponential backoff.
==========================================================
END OF MODULE 4
==========================================================
===========================================================
CKA POD MASTERY
MODULE 4 – HEALTH PROBES (MASTER NOTES)
===========================================================
############################################################
WHY KUBERNETES NEEDS PROBES
############################################################
Kubelet can only see:
Container Process
Running?
Exit Code?
It CANNOT know:
✓ Is application still loading?
✓ Is application ready?
✓ Is application hung?
✓ Can application serve requests?
Therefore Kubernetes provides three probes.
------------------------------------------------------------
STARTUP PROBE
Question:
"Can application finish startup?"
READINESS PROBE
Question:
"Can application receive traffic?"
LIVENESS PROBE
Question:
"Is application still healthy?"
------------------------------------------------------------
Think like this:
Startup
↓
Readiness
↓
Liveness
============================================================
STARTUP PROBE
============================================================
Purpose
Protect slow-starting applications.
Examples
Spring Boot
Java Applications
Large Cache Loading
Database Migration
Machine Learning Models
Flow
Container Starts
↓
Startup Probe Runs
↓
Fail
↓
Keep Waiting
↓
Fail
↓
Keep Waiting
↓
Success
↓
Disable Startup Probe Forever
↓
Enable Readiness
↓
Enable Liveness
IMPORTANT
Startup Probe runs ONLY during startup.
Once it succeeds once,
it NEVER runs again
for THAT container.
If container restarts,
Startup Probe starts again.
WHY?
Because probes belong to
container instance.
Container #1
↓
Startup Passed
↓
Container Dies
↓
Container #2
↓
Startup runs AGAIN
============================================================
REAL EXAMPLE
============================================================
Application Startup
sleep 30
touch /tmp/startup-ok
touch /tmp/ready
sleep 300
Startup checks
cat /tmp/startup-ok
Timeline
0 sec
Container Starts
↓
Startup Probe
↓
Fail
↓
Fail
↓
touch /tmp/startup-ok
↓
Startup Success
↓
Startup Disabled
↓
Readiness Starts
↓
Liveness Starts
============================================================
READINESS PROBE
============================================================
Purpose
Should this Pod receive traffic?
If Ready=True
↓
API Server updated
↓
EndpointSlice Controller
↓
Pod IP Added
↓
kube-proxy
↓
iptables/IPVS updated
↓
Traffic Starts
-------------------------------------
If Ready=False
↓
API Server updated
↓
EndpointSlice Controller
↓
Remove Pod IP
↓
kube-proxy updates
↓
NO TRAFFIC
IMPORTANT
Readiness NEVER
kills
restarts
or recreates container.
It ONLY controls traffic.
============================================================
REAL EXAMPLE
============================================================
Application Running
↓
rm /tmp/ready
↓
Readiness Probe
↓
Fail
↓
Ready=False
↓
EndpointSlice removes Pod
↓
Service Stops Sending Traffic
Container STILL RUNNING
============================================================
LIVENESS PROBE
============================================================
Purpose
Is application still alive?
If Healthy
↓
Nothing
If Unhealthy
↓
Failure Threshold Reached
↓
Kubelet
↓
Kill Container
↓
Restart Policy
↓
Restart Container
============================================================
REAL EXAMPLE
============================================================
Application
touch /tmp/ready
↓
Later
rm /tmp/ready
↓
Liveness
Fail
↓
Fail
↓
Fail
↓
Kubelet Restarts Container
============================================================
STARTUP vs READINESS vs LIVENESS
============================================================
Startup
Protect Startup
Runs once
Can Restart
No Traffic Control
-------------------------------------
Readiness
Traffic Control
Runs continuously
Never Restarts
Controls EndpointSlice
-------------------------------------
Liveness
Health Check
Runs continuously
Restarts Container
No Traffic Control
============================================================
INITIAL DELAY
============================================================
Startup initialDelay
Wait before checking startup.
Useful when app
ALWAYS needs
some minimum time.
------------------------------------------------
Liveness initialDelay
Wait before checking health.
Problem
You must GUESS startup time.
If app starts slower
↓
Liveness kills container.
This is WHY Startup Probe exists.
============================================================
FAILURE THRESHOLD
============================================================
Example
periodSeconds = 10
failureThreshold = 3
Three consecutive failures
↓
Action
Readiness
↓
NotReady
Liveness
↓
Restart
Startup
↓
Startup Failed
Restart Container
============================================================
CRASHLOOPBACKOFF
============================================================
CrashLoopBackOff
means
Container keeps restarting.
Kubelet applies
Exponential Delay
Typical
Restart
↓
10 sec
↓
20 sec
↓
40 sec
↓
80 sec
↓
160 sec
↓
300 sec
↓
300 sec
↓
300 sec
continues forever
until fixed.
============================================================
COMPLETE TIMELINE
============================================================
Container Starts
↓
Startup Probe
↓
Success
↓
Readiness
↓
Ready=True
↓
Service sends traffic
↓
Application hangs
↓
Readiness fails
↓
Traffic Stops
↓
Liveness fails
↓
Restart
↓
NEW CONTAINER
↓
Startup Probe AGAIN
============================================================
MY MISTAKES (VERY IMPORTANT)
============================================================
Mistake 1
I wrote
command:
- sleep
- 30
- touch /tmp/file
Wrong
Reason
command is NOT shell script.
First value
Executable
Remaining values
Arguments
Correct
command:
- sh
- -c
- |
sleep 30
touch /tmp/file
------------------------------------------------
Mistake 2
I thought
CrashLoopBackOff
means Pod stopped.
Reality
Pod can show
Running
while kubelet
is retrying container.
CrashLoopBackOff
is restart state,
NOT pod phase.
------------------------------------------------
Mistake 3
I thought
Readiness restart container.
Reality
Readiness NEVER restarts.
Only removes traffic.
------------------------------------------------
Mistake 4
I thought
Startup never runs again.
Reality
Startup runs again
AFTER EVERY CONTAINER RESTART.
------------------------------------------------
Mistake 5
Confused with seconds.
Solution
STOP calculating time.
Instead
Draw Timeline.
Example
Container
↓
Startup
↓
Ready
↓
Traffic
↓
Readiness Fail
↓
Traffic Stops
↓
Liveness Fail
↓
Restart
Much easier than counting seconds.
============================================================
CKA EXAM POINTS
============================================================
✓ Startup protects startup.
✓ Readiness controls traffic.
✓ Liveness restarts containers.
✓ Startup disables
Readiness & Liveness
until startup succeeds.
✓ Readiness modifies
EndpointSlice.
✓ kube-proxy updates
iptables/IPVS.
✓ Services send traffic
ONLY to Ready Pods.
✓ Startup belongs to
container instance.
✓ CrashLoopBackOff
uses exponential backoff.
============================================================
END OF MODULE 4
============================================================