Lesson 3 · Service-mesh fundamentals
The three traffic resources
Gateway, VirtualService, DestinationRule — and how a request actually flows through them.
Your win: name the three traffic-management resources, say what each governs, and trace the real request path through this repo's mesh — the mental model the rest of Part 2 fills in.
Three resources, three jobs
Istio's traffic management is configured by a small set of CRDs. Three do the core work:1
| Resource | Governs | Analogy |
|---|---|---|
| Gateway | the edge — which hosts, ports, and TLS may enter (or leave) the mesh | the front door |
| VirtualService | routing — match a request and send it to a destination (with rewrite/timeout/retry/weight) | the switchboard |
| DestinationRule | policy applied after routing — load balancing, subsets, connection pools, outlier detection | the receiving desk |
The division of labour that trips people up
A Gateway only opens a port and host — it does no routing by
itself. A VirtualService does the routing, and it can be bound to a
Gateway (for edge traffic) or apply to in-mesh traffic. A DestinationRule
kicks in after the VirtualService has picked a destination, to shape how that call
is made. Gateway = where traffic enters; VirtualService = where it goes; DestinationRule =
how it's delivered.
The request path — traced through this repo
external client
│ HTTPS
▼
[ istio-ingressgateway ] ← Gateway: terminates TLS, accepts the host
│
▼
[ VirtualService: bob-api ] ← matches /bob.v1.… → route to host "bob:5050"
│
▼
[ (DestinationRule) ] ← post-routing policy (e.g. tom's session affinity)
│
▼
[ bob Pod ] app + Envoy sidecar ← in-app grpc-gateway does REST↔gRPC transcoding
Anchor — the resources are all here
In this repo, all three come from the library chart (Course 3): the VirtualService and
DestinationRule macros live in deployments/helm/libs/util/templates/_hosts.tpl,
and the ingress Gateway is in
deployments/helm/platforms/gateway/templates/gateway.yaml
(named
<env>-<vendor>-gateway — the exact gateway each service's
VirtualService binds to). A service turns them on just by having apiHttp/
webHttp route-table values (Lesson 4).
Myth-buster: gandalf is not the gateway
You may hear "gandalf is our API gateway." In the network sense that's not true here
— the edge is
istio-ingressgateway, and gandalf is a BDD/test harness kept
out of the mesh (Lesson 2's opt-out). "gandalf = API gateway" refers to the in-app
grpc-gateway transcoding convention (REST↔gRPC inside the service, from the
gRPC course), not a proxy in the request path. Keep the two "gateways" separate.
A fourth resource, briefly
A ServiceEntry adds an external service to the mesh registry so
sidecars can route to it (Lesson 12 — this repo uses a couple for cross-cluster reach).
Gateway/VirtualService/DestinationRule are the trio to memorise first.
Backend use case
Backend use case: this is the real reading model for how edge traffic enters through the gateway, gets routed by VirtualServices, and may pick up downstream policy from DestinationRules.
Common mistake
Common mistake: treating Gateway, VirtualService, and DestinationRule like interchangeable YAML instead of three distinct control points.
Read this next
Istio docs — Traffic Management (concept)
How Gateway, VirtualService, DestinationRule (and ServiceEntry) fit together — the canonical overview.
In plain English
Plain English: Gateway, VirtualService, and DestinationRule each control a different part of the traffic story, and mixing up their roles makes Istio harder than it really is.
Check yourself (from memory)
Q1. Which resource does the actual request routing?
VirtualService matches and routes. Gateway just opens the
edge; DestinationRule shapes the call after routing.
Q2. A DestinationRule applies…
Once the VirtualService picks a destination, the
DestinationRule governs how that call is load-balanced/pooled and its subsets.
Q3. The external request path in this repo starts at…
client → istio-ingressgateway (Gateway) → VirtualService →
Pod. gandalf is a test client, not the ingress.
Name the three traffic resources, their jobs, and the request path.
recall, then click to reveal
THREE RESOURCES: GATEWAY = the EDGE (which hosts/ports/TLS enter the
mesh — the front door; does no routing itself). VIRTUALSERVICE = ROUTING (match a request →
destination, with rewrite/timeout/retry/weight; can bind to a Gateway). DESTINATIONRULE =
post-routing POLICY (load balancing, SUBSETS, connection pools, outlier detection).
Gateway=where it enters, VS=where it goes, DR=how it's delivered. REQUEST PATH (repo): client
→
istio-ingressgateway (TLS terminate) → per-service VirtualService
(apiHttp/webHttp) → Pod (in-app grpc-gateway REST↔gRPC). Repo: VS/DR
macros in _hosts.tpl, Gateway in platforms/gateway. (gandalf is a
TEST harness, NOT the ingress.) Bonus: ServiceEntry = add an EXTERNAL service to the mesh.
Want the difference between a Gateway-bound and a mesh-internal VirtualService, or how a VS
binds to a Gateway by name? Ask me — VirtualService is Lesson 4.