You’ve applied your Ingress manifest, exposed the service, opened the browser — and nothing.
No error, no logs, just the dreaded silence of a browser timeout or a blank 404. If you've worked with Kubernetes long enough, you've probably been there.
Ingress in Kubernetes is a powerful but often misunderstood abstraction. And when things don’t work, debugging it can feel like staring into a black box.
Let’s go over 7 common mistakes that cause Ingress to fail — and how to fix them.
Yes, it needs to be said. The Ingress resource alone doesn’t do anything — it’s just a declaration. It requires a controller (like NGINX, Traefik, or HAProxy) to actually route traffic.
How to check:
kubectl get pods -n ingress-nginx
Fix:
Install one using Helm or your preferred method. For example:
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm install ingress-nginx ingress-nginx/ingress-nginx
Your Ingress resource might exist, but your controller could be ignoring it.
ingressClassName: nginx
Fix:
Match the class name used by your controller. Or, if you're using an older Kubernetes version, use:
kubernetes.io/ingress.class: "nginx"
If the Ingress is configured correctly, but the referenced Service is wrong, traffic will hit a dead end.
I once spent 3 hours debugging an Ingress that "should have worked perfectly." I checked the DNS, verified the TLS certificates, restarted the ingress controller, and even questioned my life choices. The Ingress looked flawless, the controller was running, but I kept getting 503 errors.
Finally, in desperation, I ran the simplest command:
Check your service:
kubectl describe svc <your-service> kubectl get endpoints <your-service>
And there it was — zero endpoints. My service selector had a typo: app: frontend instead of app: front-end. The service existed, but it wasn't pointing to any pods. Sometimes the most obvious things are the ones we skip when we're convinced the problem is "more sophisticated."
If endpoints are empty, your service isn't pointing to any pods.
Your Ingress might look fine, but the DNS doesn’t point to the external IP of your ingress controller.
kubectl get svc -n ingress-nginx
For local testing, you can add an entry to /etc/hosts to map your domain to the ingress controller's external IP:
Get the external IP of your ingress controller:
kubectl get svc -n ingress-nginx ingress-nginx-controller
Edit your /etc/hosts file:
sudo nano /etc/hosts
Add the mapping:
<EXTERNAL-IP> myapp.example.com
For example:
192.168.1.100 myapp.example.com
For LoadBalancer services on cloud providers, the external IP might be a hostname (like an AWS ELB). In that case, use nslookup to get the actual IP:
nslookup a1b2c3d4e5f6g7h8-123456789.us-west-2.elb.amazonaws.com
For NodePort services, use any node's IP with the assigned port:
kubectl get nodes -o wide kubectl get svc -n ingress-nginx
TLS issues are common and can manifest as certificate warnings, connection refused errors, or redirects that don't work.
Check your TLS block:
tls:
- hosts:
- myapp.example.com
secretName: myapp-tls
What to check:
Verify the TLS secret exists and has the right data:
kubectl get secret myapp-tls kubectl describe secret myapp-tls
The secret should have tls.crt and tls.key fields.
Check if the certificate matches your domain:
kubectl get secret myapp-tls -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout | grep -A1 "Subject Alternative Name"
Verify the certificate hasn't expired:
kubectl get secret myapp-tls -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -enddate -noout
Check ingress controller logs for TLS errors:
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx
How to resolve:
For self-signed certificates (development):
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout tls.key -out tls.crt -subj "/CN=myapp.example.com"
kubectl create secret tls myapp-tls --key tls.key --cert tls.crt
For Let's Encrypt (production), use cert-manager:
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.12.0/cert-manager.yaml
For existing certificates, create the secret from files:
kubectl create secret tls myapp-tls --key=private.key --cert=certificate.crt
Common TLS mistakes:
Use pathType: Prefix and test both the exact and trailing slash paths.
paths:
- path: /api
pathType: Prefix
Check if any NetworkPolicy exists in the namespace:
kubectl get networkpolicy
Important: If you have a "deny-all" network policy in place, traffic from the ingress controller pods to your application pods will also be blocked. This is a common oversight that can break ingress routing even when everything else is configured correctly.
Allow ingress controller traffic explicitly:
ingress:
- from:
- podSelector:
matchLabels:
app: ingress-nginx
Ingress is one of the most powerful — and complex — parts of Kubernetes. Most problems are fixable with good diagnosis.
Note: If you're using KubeKanvas, many of these debugging steps would not be necessary. KubeKanvas provides visual clues that immediately show you if your Ingress connections are working properly. Instead of manually running kubectl commands and checking logs, you can see the connection status visually in the interface, making it much easier to identify where the problem lies in your Ingress configuration.