On this page
From the internet to your pod, and back out
Who this is for
You know your app runs in a cluster, but you're hazy on everything between a user and your code, load balancers, proxies, firewalls, and what happens when your app reaches out. This maps the whole path.
In production, a request almost never touches your application directly. It runs a gauntlet of layers, each doing one narrow job: filtering, distributing, terminating TLS, routing. And traffic leaving your cluster passes its own set of controls. Understanding the order is what lets you reason about where a problem actually is.
See it
Watch a request travel through the layers. Flip between ingress (a request coming in) and egress (your pod reaching out), and toggle a blocked request to see where, and why, it gets stopped.
The layers, live
Internet
a user / a bot
Firewall / WAF
filters attacks
Load balancer
spreads traffic
Reverse proxy
TLS + routing
Service
stable virtual IP
Pod
your app
Switch direction (ingress/egress) and toggle a blocked request to see which layer stops it.
Inbound: the layers in front
- 1
Firewall / WAF
The outer gate. A network firewall allows or denies by IP, port, and protocol; a WAF inspects the actual HTTP request and blocks attacks like SQL injection before they go any further.
- 2
Load balancer
Spreads incoming traffic across many backend nodes so no single one is overwhelmed, and quietly drops nodes that fail health checks.
- 3
Reverse proxy / ingress
The smart receptionist. Terminates TLS (handles HTTPS), then routes by hostname and URL path: api.site.com to one service, site.com to another.
- 4
Service
A stable virtual IP and name inside the cluster. Pods come and go; the Service is the steady address that always points at the healthy ones.
- 5
Pod
Finally, your actual application container handles the request and sends a response back up the same chain.
Why so many layers? (separation of concerns)
Each layer exists so the others don't have to care about its job. Your app never has to think about TLS, attack filtering, or which node is healthy. Pull a layer out and something else has to absorb its work, usually badly.
| Layer | Its one job | If it were missing |
|---|---|---|
| Firewall / WAF | Block bad traffic at the edge | Attacks hit your app directly |
| Load balancer | Spread load, route around failures | One node melts; an outage takes you fully down |
| Reverse proxy | TLS + route by host/path | Every app re-implements HTTPS and routing |
| Service | Stable address for shifting pods | Clients break every time a pod restarts |
Outbound: egress is the part people forget
Everyone guards the front door. Far fewer think about traffic leaving the cluster, which is exactly what attackers rely on. When a pod calls an external API, it typically goes: pod, to the cluster egress, source-NATed to one shared public IP at a NAT gateway, through an egress firewall that only permits approved destinations, then out.
- One stable outbound IP (NAT): partners can allow-list you, instead of an unpredictable range of pod IPs.
- Egress allow-listing: if a pod is compromised, it cannot just phone home to any server on the internet. It can only reach destinations you approved.
- Catching mistakes: a typo'd dependency or a rogue call to a random host gets blocked and logged, instead of silently succeeding.
Pro tip
A useful mental model: ingress controls who can talk to you; egress controls who you can talk to. Mature setups lock down both. Most beginners only think about ingress.
The three that get confused: LB vs reverse proxy vs API gateway
| Thing | Operates on | Main job |
|---|---|---|
| Load balancer | Connections / packets (L4) or requests (L7) | Distribute traffic across backends |
| Reverse proxy | HTTP requests (L7) | TLS termination, route by host/path, caching |
| API gateway | API calls (L7) | Auth, rate limiting, request shaping on top of routing |
Key takeaways
- Requests run a gauntlet: firewall/WAF, load balancer, reverse proxy, Service, pod.
- Each layer does one job so your app doesn't have to.
- Egress matters as much as ingress: NAT gives one outbound IP, the egress firewall allow-lists destinations.
- Ingress controls who reaches you; egress controls who you can reach.
- Load balancer vs reverse proxy vs API gateway is about the job, not the box.
Want to go deeper on the cluster side? The networking lab and the Kubernetes lab let you see these pieces for real.
Want to go deeper?
This article covers concepts taught hands-on in the Cloud Engineer and DevOps career paths, with real terminal labs, production scenarios, and structured lessons.