What is Ingress, and how does it differ from a Service?
Quick Answer
A Service exposes pods at L4 (TCP/UDP) via a stable IP; Ingress is an L7 (HTTP/HTTPS) router that maps hostnames and paths to Services, terminates TLS, and lets many sites share one load balancer. Ingress needs an Ingress controller to work.
Detailed Answer
A Service load-balances at the transport layer to pod backends. Ingress operates at the application layer: it's an API object describing HTTP routing rules — host foo.com → service A, path /api → service B — plus TLS certificates. Crucially, the Ingress object is just configuration; an Ingress controller (NGINX, Traefik, or a cloud ALB controller) actually runs the proxy and implements those rules. The big win is consolidation: instead of a costly cloud LoadBalancer per Service, you run one LoadBalancer in front of the Ingress controller and route dozens of hostnames/paths through it, with central TLS termination. The newer Gateway API is the successor, offering a richer, role-oriented model (GatewayClass/Gateway/HTTPRoute) that addresses Ingress's limitations.
Code Example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: site, annotations: { cert-manager.io/cluster-issuer: letsencrypt } }
spec:
tls: [{ hosts: [shop.example.com], secretName: shop-tls }]
rules:
- host: shop.example.com
http: { paths: [{ path: /, pathType: Prefix, backend: { service: { name: web, port: { number: 80 } } } }] }Interview Tip
Two things score points: 'Ingress is L7 config that needs a controller to enforce it,' and 'Gateway API is the modern successor.' Also mention one LB fronting many hosts as the cost win.