Ingress debugging on a bare-metal cluster has a way of turning into three different problems at once:

  • is the controller installed correctly
  • is the service exposed correctly
  • is the ingress object itself routing to the right backend

This note was really about separating those questions instead of treating “ingress is broken” as one big blob.

1. Start with Direct HTTP Checks

The first useful commands in the note were raw curl tests against the expected ingress IP:

1

curl -I -H "Host: app.example.com" http://<ingress-ip>

That is still one of my favorite first checks because it tells you quickly whether the edge path is alive before DNS enters the conversation.

2. Inspect the Ingress Objects

The next step was to look at the ingress definitions directly:

1
2

kubectl get ing -A
kubectl get ing -n <namespace> <name> -o yaml

The original note showed a mix of host-based and path-based ingress patterns. That matters, because the more complicated the rule set gets, the less useful it is to debug only from the outside.

3. Inspect the Controller, Not Just the Ingress

The note also used the right controller-level checks:

1
2
3

kubectl get svc ingress-nginx-controller -o wide
kubectl logs -f <ingress-controller-pod>
kubectl exec -it <ingress-controller-pod> -- nginx -T

That is the difference between “I applied an ingress” and “I know how the controller actually rendered it.”

4. Fix Helm Ownership Conflicts Explicitly

One of the concrete failures from the note was a Helm install conflict caused by an existing ClusterRole that was not owned by the current release:

1
2
3

invalid ownership metadata
missing key "app.kubernetes.io/managed-by"
missing key "meta.helm.sh/release-name"

The recorded fix was simple and pragmatic:

  • remove the conflicting ClusterRole
  • remove the conflicting ClusterRoleBinding
  • reinstall the ingress controller cleanly via Helm

This is a very real operational issue on clusters that have had hand-applied resources or older installs hanging around.

5. Keep the Service Exposure in Mind

The note also showed that the ingress controller itself was exposed as a LoadBalancer service through MetalLB. That is important context.

If the controller service is wrong, the ingress object can be perfectly valid and still never serve traffic from outside the cluster.

Closing Thought

The value of this note is not any one command. It is the debugging order:

  1. test the ingress IP directly
  2. inspect the ingress objects
  3. inspect the controller config and logs
  4. fix the controller installation conflicts

That order makes ingress problems much less mysterious.