A Pod includes a slow-starting metrics sidecar and a web container that should receive Service traffic only when the web app is ready. Where should the readinessProbe typically be placed?
Select an answer to reveal the explanation.
Short Explanation
Readiness is the “open for business” sign on the shop that customers actually visit. Hang that sign on the web container, not on the stockroom sidecar that’s still unpacking boxes.
Full Explanation
When a Pod includes a slow-starting metrics sidecar and a web container that should receive Service traffic only when the web application is ready, place the readinessProbe on the web app container. Service Endpoints track Pod Ready, which depends on readiness results for containers that define probes. Gating on the web container ensures residents are not routed to Pods that are only warming a metrics scraper.
Putting readiness only on the kube-proxy Pod so Services ignore application readiness misunderstands Endpoints. A DaemonSet probe on every node that gates all namespaces is not how application Services work. Claiming multi-container Pods cannot use readinessProbes is false—they commonly do.
Exam caveat: If any container with a readinessProbe fails, the Pod is not Ready. Avoid aggressive readiness on a slow sidecar unless you intentionally want traffic blocked on sidecar health. A startupProbe can protect slow containers without failing readiness immediately.
Operational check: kubectl describe pod for Readiness lines; kubectl get endpoints; fail the web readiness check and confirm the Pod drops from Endpoints while observing sidecar state separately. In municipal environments, document the chosen pattern in the service runbook so on-call engineers apply the same kubectl checks during incidents, and keep the change tied to the application Deployment or Job rather than ad-hoc node mutation.