Ingress Controllers

Analogy categoryAnalogies

An Ingress is a Kubernetes API object that describes HTTP and HTTPS routing rules, host-based and path-based, from a single external entry point to multiple internal Services, but the object by itself does nothing; it requires an Ingress controller, a separate piece of software like NGINX Ingress Controller, Traefik, or a cloud-managed ALB controller, running in the cluster and watching Ingress objects to actually provision and program a reverse proxy or load balancer. Without a controller installed, creating Ingress resources simply leaves them in a pending, unfulfilled state.

🏏

Cricket analogy: It's like a printed match schedule announcing which teams play on which ground and date, the fixture list itself doesn't run the match, it takes the actual ground staff, umpires, and broadcasters, the controller, to make the announced fixture actually happen.

Routing Rules: Host and Path Based Matching

A single Ingress resource can define rules that route api.example.com to one Service, www.example.com/blog to another, and www.example.com/* to a third, letting one external IP and one TLS certificate front an entire fleet of microservices. The pathType field controls matching precision, Exact requires the path to match character for character, Prefix matches on path element boundaries so /blog matches /blog/2024/post but not /blogger, and ImplementationSpecific defers the matching semantics to whatever the controller itself defines, which is why the same Ingress YAML can behave subtly differently across NGINX versus Traefik versus a cloud ALB controller.

🏏

Cricket analogy: It's like a single stadium hosting a tri-series where the gate you enter through, Gate A for the India match, Gate B for the Australia match, routes you to a completely different fixture even though it's all one venue and one day's event.

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: storefront
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts: ["shop.example.com"]
      secretName: shop-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: storefront-api
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: storefront-frontend
                port:
                  number: 80

TLS Termination and Certificate Management

Ingress natively supports TLS termination by referencing a Secret of type kubernetes.io/tls containing a certificate and private key for each host listed under the tls block, and the controller then handles the handshake itself, decrypting traffic before it ever reaches your Pods over plain HTTP internally. In practice almost nobody manages these Secrets manually; the cert-manager operator watches Ingress annotations like cert-manager.io/cluster-issuer, automatically requests a certificate from an ACME provider such as Let's Encrypt via HTTP-01 or DNS-01 challenge, and rotates the Secret well before the 90-day Let's Encrypt certificate expires.

🏏

Cricket analogy: It's like a stadium's ID-verification gate handling every fan's ticket and identity check at the turnstile, so once inside, fans move freely without security re-checking credentials at every stand, the heavy verification happens once at the perimeter.

TLS termination at the Ingress controller means traffic between the controller and your backend Pods travels as plain HTTP by default; if you need encryption all the way to the Pod (common in zero-trust or PCI-DSS environments), you must either enable backend TLS via controller-specific annotations or adopt a service mesh like Istio for mutual TLS at the Pod level.

Ingress Class and Multiple Controllers

A single cluster can run multiple Ingress controllers simultaneously, for example NGINX for general web traffic and a cloud-native ALB controller for a specific set of Services, and the ingressClassName field on each Ingress object determines which controller is responsible for fulfilling it; the IngressClass resource itself can also carry a ingressclass.kubernetes.io/is-default-class annotation so that Ingress objects omitting ingressClassName fall back to a designated default controller rather than being ignored by all of them.

🏏

Cricket analogy: It's like a board that runs both a T20 league and a Test championship in parallel, a specific match's format designation determines which set of umpires, rules, and broadcast rights apply, and matches without an explicit format default to whichever competition is the season's headline event.

Run kubectl get ingressclass to see every controller registered in the cluster and which one is marked default; if two IngressClasses both claim the default annotation, Kubernetes will reject the second one, so this conflict is caught at admission time rather than silently misrouting traffic.

An Ingress object only describes routing rules; an installed Ingress controller (NGINX, Traefik, ALB controller, etc.) is required to actually fulfill them.
Host-based and path-based rules let one Ingress and one external IP front many backend Services.
pathType (Exact, Prefix, ImplementationSpecific) controls matching precision and can vary in behavior across different controller implementations.
TLS is terminated at the controller by default using kubernetes.io/tls Secrets; cert-manager automates certificate issuance and rotation via ACME.
Traffic from the controller to backend Pods is plain HTTP unless backend TLS or a service mesh is explicitly configured.
ingressClassName routes an Ingress object to a specific controller when multiple controllers run in one cluster.
A default IngressClass, marked via annotation, catches Ingress objects that omit ingressClassName.