How does an Ingress resource route external HTTP/S traffic to internal Services, and what components must exist for it to function?
Quick Answer
Ingress defines host/path routing rules to backend Services. An Ingress Controller (nginx, traefik, AWS LB controller) implements the rules by configuring a load balancer or reverse proxy. Ingress alone is inert without a controller and appropriate DNS/TLS setup.
Detailed Answer
Ingress is a Kubernetes API object describing how external clients reach in-cluster Services via HTTP and HTTPS. It supports name-based virtual hosting (payments.example.com vs auth.example.com), path-based routing (/api/v1 → payments-api, /oauth → user-auth-service), TLS termination with Kubernetes secrets, and annotations for controller-specific features like rate limiting or WAF integration.
Unlike Service type LoadBalancer—which provisions one cloud LB per Service—Ingress consolidates many Services behind a single entry point, reducing cost and simplifying TLS certificate management. The Ingress spec lists rules with host, paths, pathType (Prefix, Exact, ImplementationSpecific), and backend service references with port numbers.
The Ingress object itself does nothing until an Ingress Controller watches Ingress resources and programs a dataplane. Popular controllers include ingress-nginx, Traefik, HAProxy, Kong, and cloud-specific controllers like AWS Load Balancer Controller (creates ALB/NLB) or GCE Ingress (creates Google HTTP(S) LB). cert-manager often automates Let's Encrypt certificates referenced in ingress.spec.tls.
For payments-api, you might expose https://payments.example.com/api to the payments-api Service port 80, with SSL redirect enforced via annotation. user-auth-service receives https://auth.example.com internally routed without exposing a separate LoadBalancer per microservice.
Analogy: Ingress is the building directory in a lobby. Visitors read the directory (DNS resolves to the LB), the receptionist (Ingress Controller) reads name tags (Host header) and path requests, and directs people to the correct office (Service). Without a receptionist, the directory is just a sign on the wall.
Production considerations include PROXY protocol for preserving client IP, backend protocol HTTP vs HTTPS, health check paths for cloud LBs, and Gateway API as the modern successor offering richer role separation and TCP/UDP support.
Annotations differ per controller: nginx.ingress.kubernetes.io/proxy-body-size limits upload size for payments-api, while AWS ALB annotations control target-type (ip vs instance) and WAF association. Wildcard TLS certificates (*.example.com) reduce secret sprawl when many subdomains share one Ingress. Always set resource requests (250m CPU, 512Mi memory) on the controller itself—it is on the critical path for every external request.
For zero-downtime certificate rotation, mount TLS secrets as volumes and rely on controller hot-reload rather than deleting the Ingress object. Monitor 502/504 rates at the Ingress layer separately from application golden signals to isolate dataplane regressions from code bugs.