Troubleshoot an Ingress That Returns 503 Service Unavailable
Scenario
The railway app in the railway namespace has two services, ticket and booking. An Ingress publishes them on one host:
| Endpoint | Backend |
|---|---|
http://railway.local/ticket | ticket |
http://railway.local/booking | booking |
Both endpoints fail. From cplane-01:
curl -s -i http://railway.local/ticket
HTTP/1.1 503 Service Unavailable
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Mon, 12 Oct 2026 08:08:49 GMT
Content-Length: 20
no available server
curl -s -i http://railway.local/booking
HTTP/1.1 503 Service Unavailable
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Mon, 12 Oct 2026 08:08:49 GMT
Content-Length: 20
no available server
The Deployments are applied and their Pods have started, but the app is not reachable.
The manifests the team applied are on cplane-01:
/home/laborant/railway/
├── booking-deployment.yaml
├── configmaps.yaml # immutable, do not change
├── ingress.yaml # do not change
├── services.yaml # do not change
└── ticket-deployment.yaml
Task
Make both endpoints answer with HTTP 200. Correct the Deployment manifests, ticket-deployment.yaml and booking-deployment.yaml in /home/laborant/railway/, and apply them.
Do not change the ConfigMaps, the Services or the Ingress. The ConfigMaps are immutable. Do not remove anything from the Deployments: fix what is wrong.
Hint 1 | Where the request stops
Start with the response itself: was the body written by the ingress controller or by the application?
Then follow the request from the Ingress to the Pods. In kubectl describe ingress, each backend lists in brackets the Pod addresses it can send traffic to. The EndpointSlices show whether those Pods are ready. A Pod that is Running does not always receive traffic:
kubectl describe ingress <ingress-name> -n <namespace>
kubectl get endpointslices -n <namespace>
kubectl get pods -n <namespace>
Hint 2 | Why the Pods are not ready
The events of a Pod show what the kubelet checks and what it gets back. Describe a single Pod by name:
kubectl describe pod <pod-name> -n <namespace>
The nginx logs show the same requests from the application's side. If a container keeps restarting, read the logs of its previous run:
kubectl logs <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous
Hint 3 | What nginx really serves
The nginx.conf of each app is in an immutable ConfigMap. Its listen line and location blocks show the port and the paths nginx answers on. Compare them with what Kubernetes asks it for:
kubectl get configmap <name> -n <namespace> -o yaml