Kubernetes Networking & Services
Ingress — HTTP Routing and TLS Termination
Routing external HTTP paths to services and securing certificates.
Interview: Ingress is a production routing standard. Focus on explaining the difference between an Ingress Resource (declaration) and an Ingress Controller (the actual proxy, like Nginx, Traefik, or Envoy). Understand TLS termination rules and cert-manager setups.
Why Ingress?
Using a LoadBalancer service type for every exposed application is expensive: each service provisions a new cloud provider load balancer, incurring costs and management overhead.
An **Ingress** acts as a Layer 7 (HTTP/HTTPS) reverse proxy and API Gateway inside the cluster. It consolidated routing rules into a single entry point, routing external traffic to multiple services based on request hostnames or paths.
Ingress Resource vs Ingress Controller
Ingress is split into two distinct components:
- Ingress Resource: A declarative YAML manifest containing routing rules, domain hostnames, paths, and SSL certificate secrets.
- Ingress Controller: The actual proxy application running in the cluster (e.g. Nginx Ingress Controller, Traefik, Envoy, or HAProxy) that evaluates Ingress resources and routes incoming traffic.
TLS Termination
Ingress controllers typically handle SSL/TLS termination. The controller decrypts external HTTPS traffic using SSL certificates stored in Kubernetes Secrets. Once decrypted, the controller routes the requests over standard HTTP to internal Services. This simplifies configuration management by centralizing certificate renewals and decryption processing.
Ingress Manifest Example
Here is an Ingress manifest defining path-based routing rules and TLS termination: