A cluster runs two ingress controllers, one internal and one internet-facing. How does a given Kubernetes Ingress object end up served by exactly one of them, and what goes wrong if that selection is left ambiguous?

## The two-level lookup There are three names in play and conflating them causes most confusion. 1. **The controller identifier** — a fixed, domain-prefixed string compiled into the controller, e.g. `k8s.io/ingress-nginx`. It identifies the *implementation*. 2. **The IngressClass object** — a cluster-scoped resource with `spec.controller` set to one of those identifiers, plus an optional `parameters` reference to implementation-specific config. Its *name* (`internal`, `public`) is what users type. 3. **`spec.ingressClassName` on the Ingress** — names an IngressClass. So: Ingress → IngressClass name → controller identifier → the running controller that owns it. This indirection is what lets two deployments of the *same* implementation coexist — both have `spec.controller: k8s.io/ingress-nginx`, but each is started with a flag telling it which IngressClass name to watch, so `internal` and `public` classes route to different deployments. ## Defaulting An IngressClass may carry `ingressclass.kubernetes.io/is-default-class: "true"`. When an Ingress is created without `ingressClassName`, an admission controller stamps the default class name into the object. The subtlety that trips people: **defaulting happens at creation, and the value is persisted**. If you later mark a different class default, previously created Ingresses keep the old name — they were mutated once, not re-evaluated. Conversely, an Ingress created while no default existed has an empty `ingressClassName` forever and will not start working when you add a default later. It must be edited. If **two** classes are marked default, the API server cannot choose and rejects creation of class-less Ingresses with an error. That is annoying but safe; the dangerous configuration is a single default pointing at the public controller in a cluster where most workloads are internal, because forgetting one field then publishes a service to the internet with no error anywhere. ## The legacy annotation Before `ingressClassName` existed, selection used the `kubernetes.io/ingress.class` annotation. It is deprecated, but several controllers still honour it, and where both are present the annotation typically wins. Real clusters accumulate manifests carrying both, or Helm charts that set the annotation while the operator sets the field. Any audit of "who serves what" must grep for the annotation as well as the field, and the cleanup is to remove annotations and standardise on the field. ## Failure modes and how they present - **No class, no default.** `kubectl get ingress` shows an empty `ADDRESS`, `describe` shows no events, controller logs never mention the object. Silent. - **Class name typo.** Identical symptoms — the name does not resolve to any IngressClass. Since the field is a free string, nothing validates it at creation unless you add policy. - **Two defaults.** Creation of class-less Ingresses fails outright with a clear error. - **Wrong default — the serious one.** An internal app gets picked up by the internet-facing controller. Nothing errors; DNS may not even point at it, so it can lurk until someone finds the load balancer IP. This is the case worth naming in an interview. - **Both controllers claiming one object.** Possible when one controller is configured to watch class-less Ingresses (`--watch-ingress-without-class`) while another has the default. Two data planes serve the same host, and behaviour depends on which address DNS resolves to — giving intermittent, inconsistent results. ## Operating practice Make selection explicit and enforced. Set `ingressClassName` on every Ingress and lint for its absence in CI. Either run with **no** default class — so an omission fails visibly rather than defaulting somewhere — or, if you want a default, make it the *internal* class so mistakes fail closed rather than publishing. Add an admission policy (ValidatingAdmissionPolicy, Kyverno, Gatekeeper) that rejects Ingresses whose class is empty or not in an allowed list, and optionally restricts which namespaces may use the public class. That last rule is the practical answer to "how do you stop a team exposing something publicly by accident", since Ingress itself has no namespace-scoped permission model for classes. For visibility, `kubectl get ingress -A -o custom-columns` over `spec.ingressClassName` plus a check on the legacy annotation gives an inventory in one command; `kubectl get ingressclass -o wide` shows which controller each class maps to and which is default. ## Version note `IngressClass` and `spec.ingressClassName` are part of `networking.k8s.io/v1`, GA since Kubernetes 1.19, replacing the `kubernetes.io/ingress.class` annotation, which remains deprecated-but-honoured in several controllers.