Traffic Management: Discovery Chain & Load Balancing

This is the hands-on lab for Section 8 (Gateways & Traffic Management) of the Consul 101 course. A single Ubuntu VM runs a small Docker Compose service mesh: a Consul server, a `backend` service running two versions (v1 and v2, each with its own Envoy sidecar), and a mesh client whose sidecar dials `backend` as an upstream. Every request you send flows through the real discovery chain, so the config entries you write have concrete, observable effects.

You will:

• Set the backend protocol to HTTP and author a `service-resolver` that defines

`v1` and `v2` subsets by filtering on instance metadata

• Write a `service-splitter` that sends 90% of traffic to `v1` and 10% to `v2`,

then prove the split empirically by counting responses across 200 requests

• Add a `service-router` that pins a specific path prefix to the `v2` subset

regardless of the splitter, for a canary preview URL

• Apply a hash-based load-balancing policy (`maglev` with a header hash) on the

resolver for sticky sessions, and confirm it compiles into the discovery chain

• Configure subset failover on the resolver and watch traffic shift to the

healthy version when the primary is stopped

By the end you will have used all three discovery-chain config entries and a load-balancing policy to control real mesh traffic, the exact toolkit behind canary rollouts, blue-green deploys, and session affinity.