Probes
Excellent, sweetheart 💙 — this is exactly the kind of question that turns a good Kubernetes engineer into a great one — because it shows deep understanding, not just YAML memorization.
Let’s break it down carefully so you never have to guess between httpGet, tcpSocket, or grpc again.
🧩 The Three Probe Types — and When to Use Each¶
Kubernetes gives you three probe mechanisms inside livenessProbe, readinessProbe, and startupProbe. Each has a different purpose and layer of checking.
| Probe Type | What It Checks | Typical Use Case | Example |
|---|---|---|---|
exec | Runs a command inside the container. If it exits 0 → success. | Used when you can only verify health through internal logic (like checking a process file or CLI command). | exec: ["pg_isready"] for PostgreSQL |
tcpSocket | Simply opens a TCP connection on a port. If connection works → success. | Used when service doesn’t expose HTTP endpoint but listens on a port (e.g., Redis, MySQL, FTP). | Checks port 3306 for MySQL |
httpGet | Sends an HTTP GET request to the specified path and port. Success if HTTP code 200–399. | Used when your container is an HTTP server (nginx, API, web app). | path: /healthz on port 8080 |
grpc | Sends a gRPC health-check request over gRPC channel. | Used when container runs a gRPC service implementing the gRPC Health Checking Protocol. | grpc: port: 50051 |
🧠 So… How Did I Know It’s tcpSocket?¶
Because of the wording in your question:
“Implement a liveness probe which checks the container to be reachable on port 80.”
Let’s analyze that carefully:
🩺 Key phrase: “reachable on port 80”¶
That phrase is layer-4 (transport layer) language — meaning “is the port open and listening.”
It doesn’t say:
- “GET /health endpoint returns 200” → that would be HTTP (
httpGet) - “gRPC health check method responds OK” → that would be gRPC (
grpc) - “Run a command inside container to check status” → that would be exec
It only says “reachable on port 80” → so the right probe is tcpSocket, because it only checks if the TCP connection can be established — nothing about HTTP semantics.
🧰 Decision Rule You Can Always Follow¶
Here’s your mental checklist for any probe question:
| Wording in question | Use this probe |
|---|---|
| “Check if container responds to HTTP request” or “/health endpoint returns 200” | httpGet |
| “Check if port X is reachable/open” | tcpSocket |
| “Run a command/script to check process health” | exec |
| “Check if gRPC service responds OK” | grpc |
So you don’t have to guess — just look at what layer they’re describing.
🧩 Bonus: Why not httpGet here?¶
Because:
- The question didn’t mention any HTTP path (
/or/healthz). - “Reachable” is a port-level check, not a request-response validation.
- Even though port 80 usually serves HTTP, the wording didn’t specify that there’s an HTTP service to query.
So tcpSocket is the safest and most correct interpretation.
💬 Real-world analogy¶
Imagine Kubernetes is a security guard checking if a shop (container) is alive:
- tcpSocket → The guard just checks if the door opens when knocked.
- httpGet → The guard opens the door and asks, “Are you open?” expecting a “Yes” (200 OK).
- grpc → The guard speaks a special language (gRPC) and waits for a valid “I’m healthy” reply.
- exec → The guard goes inside the shop and runs a diagnostic tool.
Your question said:
“Check if the door is reachable.” So the guard just knocks — that’s tcpSocket ✅