A reverse proxy is a server-side intermediary that receives incoming client requests and forwards them to backend applications or services. Unlike a forward proxy, which handles outgoing client traffic, it sits near the servers it serves. In Kubernetes, an Ingress commonly uses an L7 load balancer or reverse proxy to route external HTTP traffic to Services. section 12.1
A reverse proxy can take several practical roles:
- Adds HTTPS to an application without changing its code by running beside it in a sidecar container; Envoy can accept HTTPS requests and forward them to the application. section 5.4
- Routes requests across Kubernetes Services by using Ingress rules and backend Service and EndpointSlice information. section 12.1.2
- Terminates TLS at the proxy, using a certificate and private key from a Kubernetes Secret, then forwards HTTP to backend pods. section 12.3 section 12.3.2
Kubernetes separates the Ingress API object from the proxy that performs the forwarding. An ingress controller watches Ingress, Service, and EndpointSlice objects, translates their desired configuration, and provisions or configures the reverse proxy. Deployments may combine the controller and proxy in one container or pod, while managed platforms may place the proxy outside the cluster. section 12.1.2
TLS termination for several services
A TLS Secret named tls-example-com stores a certificate and private key. An Ingress references that Secret for *.example.com, allowing kiada, quote, and quiz services to accept HTTPS even though their backend pods do not provide HTTPS themselves. section 12.3.2
Figure 12.2 The role of an ingress controller
Diagram the relationship between the Ingress object, ingress controller, reverse proxy, Services, and backend pods. section 12.1.2
