A public-health Ingress returns HTTP 503 while the backing Service exists. What readiness condition commonly explains the 503?
Select an answer to reveal the explanation.
Short Explanation
Ingress is a front desk that only sends guests to staff who signed in Ready—if no Pod is Ready, visitors get a polite 503. Fix readiness before blaming cipher suites.
Full Explanation
When a public-health Ingress returns HTTP 503 while the backing Service exists, a common readiness explanation is that backend Pods are not Ready—so there are no ready endpoints and the Ingress controller has no healthy upstream. The front desk only sends guests to staff who signed in Ready. TLS secret cipher suite choice (RSA versus ECDSA) does not always yield 503; certificate problems more often present as TLS handshake errors than as 503 from empty upstreams. Disabling the API server read-only port is not translated by Ingress into 503 for application backends. ClusterIP Services are normal Ingress backends; Ingress does not require ExternalName for every backend Service. Exam caveat: Some controllers show 502/503 interchangeably for upstream problems—still check Endpoints and pod Ready conditions first. Readiness probes are frequent culprits. Operational check: kubectl get endpoints/slices and pod Ready status, fix probes or app health, confirm ready addresses appear, and retest the public-health Ingress URL. In municipal production practice, record the finding in the incident ticket with command output snippets, confirm the fix under change control, and re-validate the user-facing civic service before closing the change window.