# Ingress Has No Address

> Flags Ingresses older than 10 minutes that have no load-balancer address, so traffic has no entry point.

Source: https://zop.dev/integrations/kubernetes/recommendations/ingress-has-no-address

---

## An Ingress is only a request for a load balancer

The [Ingress documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/) 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

```bash
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](https://zop.dev/integrations/kubernetes/recommendations/ingress-without-tls). A Service of
type `LoadBalancer` with the same problem is reported by
[LoadBalancer service stuck pending](https://zop.dev/integrations/kubernetes/recommendations/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](https://docs.aws.amazon.com/eks/latest/userguide/network-load-balancing.html)
   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.