Ingresses with no load-balancer address after 10 minutes

An Ingress is only a request for a load balancer

The Ingress documentation is direct about the prerequisite: you must have an Ingress controller to satisfy an Ingress, and only creating an Ingress resource has no effect. The controller, whether ingress-nginx, the GKE controller, the AWS Load Balancer Controller or another, watches Ingresses of its class, creates or configures the load balancer, and writes the resulting address back into the Ingress status. That address is what kubectl get ingress shows in the ADDRESS column; the docs note it can take a minute or two to allocate, and you often see <pending> until then.

An Ingress with no address after several minutes means that chain broke somewhere. No controller claims the class, the controller is crashing, or it tried to create a cloud load balancer and the cloud said no. Until it is fixed, the hostnames routed through that Ingress lead nowhere.

Listing Ingresses without an address

kubectl get ingress -A -o json | jq -r '
  .items[]
  | select((.status.loadBalancer.ingress // []) | length == 0)
  | "\(.metadata.namespace)/\(.metadata.name) class=\(.spec.ingressClassName // "none") created=\(.metadata.creationTimestamp)"'

Check which classes exist and which one is default with kubectl get ingressclass.

Pending, and older than ten minutes

ZopNight fires when it reads the Ingress as pending, meaning no load-balancer address, and the Ingress is at least 10 minutes old by its creation timestamp. Cloud load balancers take a few minutes to provision, and the age floor keeps a new Ingress from being flagged while that is still happening. If the creation time is missing, the rule stays silent. The condition is read point in time; once an address appears, the next evaluation clears the finding.

Where the check stops

The rule reports the symptom, not the cause, and it does not inspect the controller, the IngressClass or the backend Services. Ingresses that do have an address but serve plain HTTP are the subject of Ingress without TLS. A Service of type LoadBalancer with the same problem is reported by LoadBalancer service stuck pending.

Broken routing, no savings figure

This medium-severity reliability finding carries no dollar amount. The impact is that every route defined on the Ingress is unreachable from outside the cluster.

Working out where the chain broke

1. Run kubectl describe ingress <name> and read the events; controllers usually report why they could not provision.
2. Confirm spec.ingressClassName matches an existing IngressClass, or that a default class is defined if the field is omitted.
3. Check the controller’s pods are running and read their logs.
4. On EKS with the AWS Load Balancer Controller, confirm the subnets carry the role tags the EKS load balancing guide describes, such as kubernetes.io/role/elb set to 1 for internet-facing load balancers.
5. Once the address appears, update DNS to point the hostnames at it.