nginx vs Kubernetes Ingress & Cloud Load Balancers

Once a workload moves onto Kubernetes or a cloud provider, the reverse-proxy job nginx does locally doesn't disappear — it moves, and sometimes reappears as nginx itself, one layer out or one layer in.

TL;DR — in 30 seconds:

• The same three jobs — routing, TLS termination, load balancing — repeat at three layers: standalone nginx (one host), a Kubernetes Ingress controller (one cluster), and a cloud load balancer (the provider's network).
• One of the most widely used Ingress controller implementations is, in fact, nginx itself, configured dynamically from Ingress objects instead of a hand-written config file.
• A real deployment commonly stacks all three: cloud load balancer → Ingress controller → Kubernetes Service → Pod.

1. Same job, different layer

• A standalone nginx server in front of a single host does routing, TLS termination, and load balancing for whatever runs on that host — everything covered in the previous three pages.
• A Kubernetes Ingress object asks the cluster's Ingress controller to do the exact same three jobs — routing by hostname/path, TLS termination, load balancing — but for Services running inside the cluster instead of processes on one host. One of the most widely used Ingress controller implementations is, in fact, nginx itself, configured dynamically from Ingress objects instead of a hand-written config file.
• A cloud load balancer (for example, an AWS Application or Network Load Balancer) does the same job again, one layer further out — in front of the cloud provider's own compute instead of a single host or a cluster.

flowchart LR
    C["Client"] --> CLB["Cloud load balancer<br/>(e.g. ALB)"]
    CLB --> IC["Ingress controller<br/>(often nginx itself)"]
    IC --> SVC["Kubernetes Service"]
    SVC --> POD["Pods"]

2. Comparing the three layers

Layer	Scope	Who configures it
Standalone nginx	One host's processes	Hand-written nginx.conf server/location blocks
Kubernetes Ingress controller	Services inside one cluster	Ingress objects, watched and enforced by the controller
Cloud load balancer	Compute across the provider's network	Provider-managed resources (e.g. an ALB)

3. Picking the right layer

These layers aren't a strict either/or — a real deployment commonly stacks them: a cloud load balancer in front of a cluster's Ingress controller, which routes to a Kubernetes Service, which reaches a Pod. Each layer does routing/TLS/load-balancing at its own scope; module 04 (Kubernetes & Helm) and module 05 (AWS) cover the cluster-side and cloud-side pieces this module's standalone-nginx config generalizes into.

4. How this connects

• Everything nginx does standalone in this module — server/location matching, TLS termination, upstream load balancing — is the same job the Ingress controller and cloud load balancer perform one layer out; nothing new to learn, only a new place the same job runs.
• This closes the module: reverse proxy → TLS termination → proxying/load balancing → the same job at larger scale.

You can defend this when you can name, for a request reaching a Pod inside a cluster behind a cloud load balancer, which of the three layers is doing the routing, which is doing TLS termination, and why an Ingress controller being "often literally nginx" isn't a coincidence.