Why Your Ingress Isn't Working — 7 Common Kubernetes Mistakes

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.

1. No Ingress Controller Installed

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

2. Ingress Controller Not Matching Your Resource

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"

3. Backend Service Misconfigured or Missing

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.

4️⃣ Hostname Doesn’t Resolve

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:

1. Get the external IP of your ingress controller:

   kubectl get svc -n ingress-nginx ingress-nginx-controller
   

2. Edit your /etc/hosts file:

   sudo nano /etc/hosts
   

3. Add the mapping:

   <EXTERNAL-IP> myapp.example.com
   

   For example:

   192.168.1.100 myapp.example.com
   

4. 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
   

5. For NodePort services, use any node's IP with the assigned port:

   kubectl get nodes -o wide
   kubectl get svc -n ingress-nginx
   

5. TLS Not Working or Misconfigured

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:

1. 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.

2. 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"
   

3. Verify the certificate hasn't expired:

   kubectl get secret myapp-tls -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -enddate -noout
   

4. 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:

• Host in TLS block doesn't match the host in rules
• Secret is in wrong namespace (must be same as Ingress)
• Certificate doesn't include all domain variants (with/without www)

6️⃣ Path-Based Routing Doesn’t Match

Use pathType: Prefix and test both the exact and trailing slash paths.

paths:
  - path: /api
    pathType: Prefix

7. Network Policies Are Blocking Traffic

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

Final Thoughts

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.