1. Live data plane — two gateway tiers
On this cluster every Gateway gets its own dedicated ELB on Swiss OTC. Requests reach pods one of two ways: a shared platform Gateway that fans many apps out from a single ELB, or the Own-Gateway-Tier, where each tenant or app runs its own Gateway behind a dedicated ELB. Both lanes below are live; the coloured dots are continuously-animated request packets.
*.wolfslight.cc apps out at L7
2. Step by step, request then response
What actually happens at each box, in milliseconds. Numbers point forward; ↩ points back.
browserYou hit the URL
curl https://gateway.wolfslight.cc/. Browser asks DNS for the A-record → 185.153.106.188, opens a TCP socket to port 443, and starts a TLS handshake with Host: gateway.wolfslight.cc.
internetOTC edge accepts the connection
The EIP is BGP-advertised from Open Telekom Cloud's Swiss-region edge routers. Your packet enters the OTC network and is routed to this Gateway's dedicated union-ELB, bound to this EIP.
elbL4 ELB forwards to the Envoy data plane
The dedicated ELB operates at OSI layer 4 (TCP). It health-checks the Envoy proxy pods behind their NodePort, picks a healthy one, and forwards the raw connection — no HTTP awareness yet.
envoyEnvoy terminates TLS and routes at L7
Envoy — the Gateway data plane — terminates the Let's Encrypt cert (gateway-wolfslight-tls), reads Host + path, applies the SecurityPolicies (cors-features on /features, secret-basic-auth on /secret) and the Local rate-limit (60 req/min per route), then matches an HTTPRoute to a ClusterIP backend.
podThe matched backend serves the response
Envoy forwards to the ClusterIP Service — ui (this Kong-served page), echo/echo-v2 (a canary traffic-split on /demo), hello, secret-page or slow — which writes 200 OK back through Envoy.
podResponse leaves the pod
The backend writes the body. Linux's network stack forwards it via the pod's veth pair through the CNI back to the Envoy proxy pod.
envoyEnvoy streams it back over the client's TLS session
Envoy adds the security-header set (HSTS, X-Content-Type-Options, X-Frame-Options, …), re-encrypts on the established TLS connection, and hands bytes to the ELB.
elbELB writes back on the same TCP connection
Layer-4 means the ELB doesn't terminate TLS or rewrite HTTP — it just streams the encrypted bytes back to the OTC edge and on to you.
browserBrowser renders the page
~30–80 ms after the click, depending on RTT — the full round-trip through a dedicated ELB and one L7 Envoy hop.
3. Two paths through the cluster
Both provision a real OTC union-ELB via the same cloud-controller path. They differ in who owns the Gateway — and whether that ELB is shared across many apps or dedicated to a single tenant or app.
Shared platform Gateway
One ELB, many apps. The platform team owns it.
- Browser → OTC Edge
- OTC Edge → ELB
platform(185.153.106.138) - ELB → Envoy (platform data plane)
- Envoy → app matched by Host — e.g. headlamp / forgetales / flux-webhook (not an exhaustive list, see below)
Wildcard TLS *.wolfslight.cc. An app just adds an HTTPRoute — no new ELB, ever. That's the whole point: the app count behind this Gateway grows without touching the ELB. Stand 2026-08-26: 4 apps. The global HTTP→HTTPS redirect lives here too.
Own-Gateway-Tier
Your own Gateway ⇒ your own dedicated ELB. 5 hops to the pod.
- Browser → OTC Edge
- OTC Edge → dedicated ELB (Envoy Gateway provisions one per Gateway)
- ELB → Node NodePort
- Node → your Envoy proxy pod
- Envoy → matched backend pod (HTTPRoute / SecurityPolicy / rate-limit)
This is how tenants get in: type=LoadBalancer is blocked in tenant namespaces (Capsule serviceOptions + a 0 LB ResourceQuota + a Kyverno audit rule), so a tenant is granted the Own-Gateway-Tier instead. gateway-demo, coder, secpol-demo and tenant gateclear each run their own ELB — full L7: path/host/header/method matching, traffic split, TLS termination, CORS, Basic Auth, rate-limit, security headers.
4. Every app earns its own Gateway — and its own ELB
Own-Gateway-Tier means exactly that: one Gateway, one dedicated ELB, no
exceptions. Every card below is a real, OTC-provisioned union-ELB with
its own EIP, each fronting an Envoy Gateway. type=LoadBalancer
Services are banned in tenant namespaces — the Own-Gateway-Tier is how you
earn an ELB here. The number of live Gateways/ELBs grows as apps are added;
it does not stay fixed — snapshot: kubectl get gateways -A
counts 8 as of 2026-08-26. Five examples below.
gateway-demo · this demo
185.153.106.188. Own-Gateway-Tier. Envoy behind one ELB: HTTPS + HTTP→HTTPS redirect, echo/echo-v2 traffic-split on /demo, CORS on /features, Basic Auth on /secret, a Local 60 req/min rate-limit — and the ui backend serving this page.
platform · shared gateway
185.153.106.138. One ELB, wildcard TLS *.wolfslight.cc, fanning apps out at L7 by Host — e.g. headlamp, forgetales-app, flux-webhook (Stand 2026-08-26: 4 apps, not a closed list) — plus the cluster-wide HTTP→HTTPS redirect.
secpol-demo · IP allowlist
185.153.106.140. Own-Gateway-Tier. A dynamic IP allowlist enforced by an Envoy SecurityPolicy — not an ELB ACL — with a custom 403 page.
coder · Own-Gateway-Tier
185.153.107.161. The Coder workspace platform on its own Gateway and dedicated ELB.
gateclear · tenant gateway
138.124.232.249. A Capsule tenant (airgate) running its own Gateway and dedicated ELB — the Own-Gateway-Tier in the hands of a real tenant.