How a request reaches an app

Say you open https://app.example.com in a browser. Here's the whole journey:

browser
  |  https://app.example.com
  v
DNS  ->  203.0.113.10        (public IP on the gateway)
  |
  v
pfSense / HAProxy            terminates TLS (wildcard *.example.com),
  |                          forwards plain HTTP, keeps the Host header
  v
10.100.100.100 : 80          MetalLB-assigned LoadBalancer IP (Kong proxy)
  |
  v
Kong (API gateway)           matches the Host/route, applies plugins
  |
  v
Kubernetes Service  ->  Pod  the actual application
        |                \
        v                 v
   the databases       logs -> Loki
   (.13 / .14 / .15)   metrics -> Grafana

The important idea: TLS is handled once, at the edge. Nothing inside the cluster deals with certificates. Kong, the apps, the registry — they all speak plain HTTP on the private network and trust that HAProxy already did the encryption out front. That keeps certificate management in exactly one place.

Lesson learned. I originally set Kong up to terminate its own TLS. It worked, but it meant two places owning certificates and an awkward redirect loop once HAProxy sat in front of it. Moving termination fully to the edge made the whole thing simpler — the gateway just serves HTTP and lets the edge worry about HTTPS. When you find yourself configuring TLS in two layers, that's usually a smell.