Ingress and ingress controllers

Ingress solves one problem: you do not want to spin up a separate cloud LoadBalancer for every service. One LB, one IP, smart routing by host and path to many Services behind it.

How it splits

• Ingress resource: a Kubernetes object that says "host api.foo.com path /users goes to Service users-svc:8080."
• Ingress controller: the actual process that reads Ingress objects and configures something to route traffic. NGINX, Traefik, HAProxy, AWS ALB Controller, Istio Gateway.

The Ingress resource without a controller does nothing. The controller without Ingresses runs idle.

Common controllers

• ingress-nginx: most common, runs NGINX in a Pod. Good for most workloads, mature.
• AWS Load Balancer Controller: provisions ALBs directly, target type ip sends to Pods bypassing kube-proxy. What you want on EKS.
• Traefik: dynamic config, good DX, popular outside cloud.
• Istio Gateway: if you already run Istio, use this.

TLS

Ingress handles TLS termination. You reference a Secret containing the cert and key. Cert-manager automates Let's Encrypt issuance and renewal via ACME. Combine cert-manager + an Ingress controller and TLS becomes a tls: block in your Ingress.

Gateway API: the replacement

Ingress is getting old. The Gateway API is the next-gen replacement, GA since 1.29. It splits into three roles:

• GatewayClass: cluster admin defines what infrastructure (NGINX, ALB).
• Gateway: platform team defines the listener (port, TLS, hostnames).
• HTTPRoute / TCPRoute / GRPCRoute: app team defines routing rules.

Cleaner separation, native multi-team support, real protocol-level types instead of annotations. New projects should default to Gateway API.

The interview answer

Ingress is a config object, the controller is the worker. ingress-nginx is the default choice, AWS Load Balancer Controller for EKS production, Gateway API is where new clusters should start. TLS via cert-manager.