Lesson 5 · Traffic, the edge & resilience

Gateway & ingress

The mesh's front door — terminating TLS and letting the right hosts in — and why it isn't gandalf.

Your win: explain what an Istio Gateway does (vs a VirtualService), how the ingress gateway terminates TLS at the edge, and trace the full external request path in this repo.

The Gateway opens a door — nothing more

A Gateway configures a standalone Envoy running at the edge of the mesh (the ingress gateway, a separate Deployment — not a sidecar). It declares which hosts, ports, and TLS the mesh will accept. Crucially, it does no routing by itself — a VirtualService bound to the Gateway decides where the traffic goes.1

Gateway vs the old Kubernetes Ingress A Gateway is Istio's richer replacement for a plain Kubernetes Ingress: it only defines the L4–L6 edge (host + port + TLS), and hands L7 routing to VirtualServices. That separation — "open the door" vs "route the traffic" — is exactly Lesson 3's division of labour, applied at the edge.

The ingress gateway in this repo

Anchor — platforms/gateway/templates/gateway.yaml The ingress Gateway selects the ingress Envoy with selector: istio: ingressgateway (:9) and is named <env>-<vendor>-gateway (helper gateway/templates/_helpers.tpl:13) — the exact name each service's VirtualService binds to (gateways: istio-system/<env>-<vendor>-gateway, Lesson 4). Its servers are all protocol: HTTPS with tls.mode: SIMPLE and a credentialName: cert-*:
TLS terminates at the edge — SIMPLE, not MUTUAL tls.mode: SIMPLE means the gateway presents a server certificate and terminates HTTPS here, at the edge (cert delivered via SDS / cert-manager). It is not MUTUAL — clients aren't required to present a cert. And inside the mesh, traffic onward is plaintext (Lesson 1's "no in-mesh mTLS"). So the security boundary in this repo is the edge: TLS to the outside world, then trusted in-cluster traffic. There's also a Cloudflare front Gateway that does httpsRedirect: true (HTTP→HTTPS, gateway-cloudflare.yaml:54).

The full request path

external client │ HTTPS (TLS terminated here, mode SIMPLE) ▼ [ istio-ingressgateway ] ← Gateway "<env>-<vendor>-gateway": host + port + cert │ (plaintext onward, in-cluster) ▼ [ VirtualService: bob-api ] ← bound to that Gateway; routes by URI │ ▼ [ bob Pod: app + Envoy ] ← in-app grpc-gateway does REST↔gRPC
Reminder: gandalf is not on this path The edge is istio-ingressgateway. gandalf is a BDD/test harness kept out of the mesh (Lesson 2/3) — no Gateway or VirtualService routes to it. If asked "how does external traffic get in?", the answer is the Istio ingress gateway, full stop.
Backend use case Backend use case: this clarifies the real request path through `istio-ingressgateway` and prevents the recurring confusion that gandalf is the ingress layer.
Common mistake Common mistake: calling gandalf the ingress gateway instead of recognizing it as a separate test/transcoding concept off the main ingress path.
Read this next

Istio docs — Gateway (reference)

The selector/servers/tls fields, and how a VirtualService binds to a Gateway.

→ istio.io — Gateway

In plain English Plain English: the Gateway is the mesh edge door, where incoming traffic and edge TLS are actually accepted before routing happens.

Check yourself (from memory)

Q1. An Istio Gateway is responsible for…

The Gateway opens a host/port/TLS at the edge; a bound VirtualService does the routing.

Q2. tls.mode: SIMPLE on the ingress gateway means…

SIMPLE = present a server cert, terminate HTTPS at the edge. Not MUTUAL; in-mesh traffic is plaintext here.

Q3. External traffic enters this repo's mesh through…

Client → istio-ingressgateway (Gateway) → VirtualService → Pod. gandalf is a test harness, off the path.
What does a Gateway do, how does the edge TLS work here, and the request path?
recall, then click to reveal
A GATEWAY configures the edge Envoy (a standalone ingress Deployment, not a sidecar): which HOSTS, PORTS, and TLS enter the mesh — it does NO routing (a bound VirtualService does). It's Istio's richer replacement for a K8s Ingress. REPO: platforms/gateway/templates/gateway.yaml, selector: istio: ingressgateway, named <env>-<vendor>-gateway (what VSes bind to). Servers are HTTPS, tls.mode: SIMPLE (server cert, terminate at edge — NOT mutual), on ports 443/31400(web)/31500(grpc)/31600(admin); Cloudflare front does httpsRedirect. So the security boundary is the EDGE: TLS outside, plaintext in-cluster. PATH: client → istio-ingressgateway → VirtualService → Pod. gandalf is NOT the ingress.
Want to see how SDS/cert-manager delivers the cert, or the difference between a Gateway and a Kubernetes Ingress in detail? Ask me.

1. Istio — Gateway reference.