A TCP-only batch worker for meter readings has no HTTP server. Which probe type correctly checks that its listen port is open?
Select an answer to reveal the explanation.
Short Explanation
No web UI? No problem—just ask whether the socket answers. A tcpSocket probe checks that the worker’s port is accepting connections. Inventing fake HTTP or remote website checks doesn’t prove this process is listening.
Full Explanation
A TCP-only batch worker for meter readings with no HTTP server should use a tcpSocket probe against the worker’s listen port. tcpSocket checks that something accepts TCP connections on that port—appropriate for non-HTTP municipal workers where inventing an HTTP stack solely for probes would be artificial.
Why the other options fail by concept: Requiring httpGet on /healthz when no HTTP stack exists yields permanent probe failures. A grpc probe without enabling gRPC health on the worker will not correctly reflect status. A startupProbe that httpGets example.com from inside the Pod tests Internet reachability, not the worker’s listen port.
Exam caveat: Open ports do not guarantee the worker is logically healthy—tcpSocket is shallower than an application-level check, but it is the correct probe type when only TCP is available. Combine with exec probes if a CLI check can assert deeper meter-worker health. Still use startupProbe if initialization is long before the port binds.
Operational check: Configure tcpSocket.port to the worker’s listen port, apply, and verify Ready/liveness behavior with kubectl describe pod. Stop the listener inside a debug scenario and confirm probes fail without needing an HTTP endpoint.