HTTP rules on an Ingress work, but HTTPS for the listed host fails. kubectl shows the tls Secret name referenced by the Ingress does not exist. What is the likely diagnosis?
Select an answer to reveal the explanation.
Short Explanation
HTTP can still work while HTTPS is broken—the front desk answers on 80 but has no key for 443. A missing or wrong TLS Secret is the usual smoking gun. Fix or create that Secret and re-point tls.
Full Explanation
If HTTP rules on an Ingress work but HTTPS for the listed host fails, and kubectl shows the tls Secret name referenced by the Ingress does not exist, the likely diagnosis is that HTTPS termination fails because the referenced TLS Secret is missing or incorrect, while HTTP rule matching can still succeed. Controllers need the Secret material to serve TLS certificates; a missing Secret breaks HTTPS without necessarily removing HTTP routes for the same host.
ClusterIP Services do not reject HTTPS whenever any Ingress exists in the namespace. Readiness probes are not required to use https:// for TLS Secrets to be honored by Ingress—probe scheme is independent of Ingress TLS Secret presence. Missing TLS Secrets also do not automatically convert all Services to ExternalName.
Exam caveat: the Secret is typically type kubernetes containing tls.crt and tls.key and must exist in the Ingress’s namespace for common controllers. Operational check: kubectl get secret <name>; create or correct the Secret and secretName reference; curl https://host and verify the certificate chain; kubectl describe ingress for TLS-related events. Follow city certificate issuance and rotation playbooks rather than disabling HTTPS to “make it work.”