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.
Read this next
Istio docs — Traffic Management (concept)
How Gateway, VirtualService, DestinationRule (and ServiceEntry) fit together — the canonical overview.
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.