# Ingress

> Ingress objects route external HTTP traffic to Services through a controller-managed load balancer shared across the class. ZopNight marks an Ingress pending until it has an address, records ingressClassName, hosts, rules, and a tlsEnabled flag, and raises RC-1720/1820/1920 (high severity) for any Ingress serving without TLS, exempting only cert-manager's cm-acme-http-solver Ingresses.

Source: https://zop.dev/integrations/kubernetes/ingress
Updated: 2026-08-19

---

An Ingress declares HTTP routing rules (which hosts and paths reach which Services) and hands them to an ingress controller to implement. The object is free and shares its controller's load balancer with every other Ingress in the class, which is exactly what makes it the cheaper alternative to per-Service LoadBalancers.

## Pending until the controller answers

An Ingress with no load-balancer address in its status maps to `pending`: either the controller has not reconciled it yet, or no controller matches its `ingressClassName` at all, a misconfiguration that otherwise fails silently. Once addressed, it reports `active`. Discovery keeps the class name, the host list, the routing rules, the TLS host list, and a computed `tlsEnabled` flag per object.

## The no-TLS rule and its one deliberate exception

Ingress Without TLS (RC-1720 / RC-1820 / RC-1920, high severity) fires on any Ingress whose spec configures no TLS section: traffic between clients and the controller travels plaintext. The rule carries exactly 1 unconditional exemption, for Ingresses whose name starts with `cm-acme-http-solver-`. Those are created by cert-manager to answer ACME HTTP-01 challenges, must serve plain HTTP for domain validation to work, and exist precisely to obtain the certificate whose absence the rule would otherwise flag. When the TLS flag cannot be determined the rule abstains instead of guessing.

## Hosts and rules as discovered topology

The recorded hosts and per-path backend rules turn the Ingress inventory into a routing map: which external names exist, which Services they land on, and which Ingresses route to Services that no longer resolve. Read next to the EndpointSlice data, that answers the practical question behind most incident pages. Does this hostname currently lead to any ready pod?

```bash
kubectl get ingress -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,CLASS:.spec.ingressClassName,HOSTS:.spec.rules[*].host,TLS:.spec.tls[*].hosts,ADDRESS:.status.loadBalancer.ingress[0].hostname
```

## One frontend, many routes

Because all Ingresses in a class share one controller-managed load balancer, adding a route costs nothing while adding a LoadBalancer Service adds an hourly meter. Consolidating stray LoadBalancer Services behind the existing Ingress class is the standing recommendation the two Service-type advisories point toward.