📖 Scenario: You are deploying a web application in Kubernetes. To ensure your app is running and healthy, you need to configure an HTTP readiness probe. This probe will check if the app is ready to serve traffic by sending HTTP requests to a specific path.
🎯 Goal: Configure an HTTP readiness probe in a Kubernetes Pod manifest that checks the /health endpoint on port 8080.
📋 What You'll Learn
Create a Pod manifest with a container named webapp using the image nginx:latest.
Add an HTTP readiness probe to the container that sends requests to /health on port 8080.
Set the probe's initial delay to 5 seconds and period to 10 seconds.
Print the final Pod manifest YAML.
💡 Why This Matters
🌍 Real World
HTTP probes help Kubernetes know when your app is ready to receive traffic and when it needs restarting, improving reliability.
💼 Career
Configuring readiness and liveness probes is a common task for DevOps engineers and site reliability engineers managing Kubernetes workloads.
Progress0 / 4 steps
1
Create the basic Pod manifest
Create a Kubernetes Pod manifest named pod.yaml with a spec that includes one container named webapp using the image nginx:latest. Do not add any probes yet.
Kubernetes
Hint
Start with the basic Pod structure and add one container named webapp with the nginx:latest image.
2
Add the HTTP readiness probe configuration
Add a readinessProbe section under the webapp container. Configure it to use an httpGet action that targets path: /health and port: 8080.
Kubernetes
Hint
Use readinessProbe with httpGet specifying the path and port.
3
Set initial delay and period for the readiness probe
Under the readinessProbe, add initialDelaySeconds: 5 and periodSeconds: 10 to control when the probe starts and how often it runs.
Kubernetes
Hint
These settings tell Kubernetes to wait 5 seconds before the first probe and then check every 10 seconds.
4
Print the final Pod manifest
Print the complete Pod manifest YAML to verify your HTTP readiness probe configuration.
Kubernetes
Hint
Use a print statement to output the full YAML manifest as a string.
Practice
(1/5)
1. What is the main purpose of an HTTP probe in Kubernetes?
easy
A. To deploy new versions of the application automatically
B. To store application logs for debugging
C. To check if the application is running and responding to HTTP requests
D. To manage network traffic between pods
Solution
Step 1: Understand the role of HTTP probes
HTTP probes send HTTP requests to the app to check if it is alive and ready.
Step 2: Identify the correct purpose
Only To check if the application is running and responding to HTTP requests describes checking app health via HTTP requests.
Final Answer:
To check if the application is running and responding to HTTP requests -> Option C
Quick Check:
HTTP probe purpose = health check [OK]
Hint: HTTP probes test app health by sending HTTP requests [OK]
Common Mistakes:
Confusing probes with deployment or logging
Thinking probes manage network traffic
Assuming probes store logs
2. Which of the following is the correct syntax to define an HTTP liveness probe in a Kubernetes pod spec?
easy
A. livenessProbe:
exec:
command: ["curl", "/healthz"]
initialDelaySeconds: 5
periodSeconds: 10
C. livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
D. livenessProbe:
httpGet:
url: http://localhost:8080/healthz
initialDelaySeconds: 5
periodSeconds: 10
Solution
Step 1: Review HTTP probe syntax
The correct HTTP probe uses httpGet with path and port keys.
Step 2: Identify the correct YAML structure
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10 correctly uses httpGet with path and port. livenessProbe:
httpGet:
url: http://localhost:8080/healthz
initialDelaySeconds: 5
periodSeconds: 10 is invalid because url is not a valid key.
Final Answer:
Correct HTTP liveness probe syntax with httpGet, path, and port -> Option B
Quick Check:
httpGet uses path and port keys [OK]
Hint: Use httpGet with path and port, not url [OK]
Common Mistakes:
Using 'url' instead of 'path' in httpGet
Confusing exec or tcpSocket probes with httpGet
Wrong indentation or missing keys
3. Given this probe configuration snippet in a pod spec:
But Kubernetes marks the pod as not ready even though the app is healthy. What is the likely problem?
medium
A. The probe path /ready is incorrect or not handled by the app
B. initialDelaySeconds is too high, delaying readiness
C. timeoutSeconds is too long, causing probe to fail
D. periodSeconds is too short, causing probe overload
Solution
Step 1: Check probe path correctness
If the app does not respond correctly to /ready, probe fails and pod is not ready.
Step 2: Evaluate timing parameters
initialDelaySeconds of 5 is reasonable; timeoutSeconds of 2 is short but typical; periodSeconds of 10 is normal.
Final Answer:
The probe path /ready is incorrect or not handled by the app -> Option A
Quick Check:
Probe path must match app endpoint [OK]
Hint: Check if probe path matches app endpoint exactly [OK]
Common Mistakes:
Ignoring probe path correctness
Changing timing values unnecessarily
Assuming timeoutSeconds causes readiness failure
5. You want to configure a Kubernetes HTTP readiness probe that waits 15 seconds after container start, then checks the path /health every 3 seconds, but fails the pod if no response within 1 second. Which is the correct probe configuration snippet?