Skip to main content

Workflow: Shadow / Dark Launch

Mirror a percentage of live production traffic to a new version for validation — without affecting any real users. Responses from the new version are silently discarded.

Important Concepts (Mirror vs Canary)​

Mirroring (*-mirror) and Weighted Round Robin (*-wrr canary) are fundamentally different. Do not repoint a production *-wrr IngressRoute without explicit sign-off, as it removes real-user canary exposure.

Before (*-wrr weighted canary)After (*-mirror traffic shadowing)
A fraction of real user requests is served by the canary.All end-user responses come from the stable/main service.
Clients receive either a canary or stable response.Canary only receives mirrored (duplicated) requests.
Production traffic is actively split.Canary responses are completely discarded by Traefik.
Side Effects

Shadow traffic does reach your canary pods. If the new version writes to a database, sends emails, or triggers other side effects, shadow mode will execute them for real. Use shadow launch only for read-heavy or idempotent services, or route shadow traffic to an isolated database.

Workflow Scenarios (Tools & Resources)​

Scenario A: Progressive Shadow Launch​

Tests the traefik_manage_traffic_mirroring tool combined with anomaly resources.

StepActionTool / Resource
1Enable MirroringTool: traefik_manage_traffic_mirroring — action=enable, route_name, namespace, mirror_percent, optional main_service / mirror_service (defaults {route_name}-stable / {route_name}-staging), optional attach_to_ingress (default false).
Example: action=enable, attach_to_ingress=false.
Creates {route_name}-mirror. Response includes status and warnings.
2Activate Mirror in IngressOption A: Step 1 with attach_to_ingress=true (MCP merge-patches Ingress to {route_name}-mirror). ⚠️ Ends live weighted user split.
Option B: GitOps / kubectl: set Ingress services[0].name to {route_name}-mirror.
3Evaluate MetricsResources: traefik://traffic/routes/list (mirror stats); traefik://traffic/{ns}/{route}/distribution (traffic_split.type set to mirror); traefik://traffic/ingressroutes/list (live targets).
4Anomaly / signalsResource: traefik://anomalies/detected
5Ramp MirroringTool: traefik_manage_traffic_mirroring with action=update (mirror_percent=50).
6Rollback (Disable)Tool: traefik_manage_traffic_mirroring with action=disable, restore_ingress_to_wrr=true — repoints Ingress to {route_name}-wrr, then deletes {route_name}-mirror. Use restore_ingress_to_wrr=false only if you will repoint the Ingress yourself.

Natural Language Prompts​

These prompts demonstrate how operators interact with the Traefik MCP server. The agent uses traefik_manage_traffic_mirroring and traefik:// traffic resources under the hood.

1. Set up shadow traffic (Create mirror only)​

Don’t switch the live ingress yet.

"We’re doing a shadow launch on prod. For the api-service ingress route in production, set up traffic mirroring: send a copy of 20% of traffic to the canary service for observation, but keep user-facing traffic going through stable for now. Use api-service-stable as the real backend and api-service-canary as the shadow. Don’t repoint the ingress to the mirror yet — I only want the mirror TraefikService created. After you run it, tell me what warnings came back and whether the mirror is actually active on the cluster or still waiting on an ingress change."

2. Turn on shadow and wire the ingress​

Full shadow — accepts losing the live weighted split.

"Turn on traffic mirroring for api-service-route in production: 20% shadow to api-service-canary, stable responses from api-service-stable. Go ahead and update the ingress so traffic goes through the mirror setup. Remind me what that changes for real users vs the old 50/50 weighted canary."

3. Check what the cluster thinks (List + Distribution)​

"I want to sanity-check our shadow launch. Show me all Traefik traffic services that are doing mirroring — main service, ports, and what percentage is copied to shadow. Then pull the detailed traffic view for api-service-route in production and explain in plain language whether we’re on weighted canary or mirror and which service is the “main” sink."

"Which TraefikService is our api-service-route ingress actually pointing at right now — the weighted one or the mirror?"

4. Ramp shadow percentage​

"Shadow has been stable; bump the mirroring from 20% to 50% for api-service-route in production."

5. Anomalies & Health Signals​

"Run a traffic anomaly check for api-service-route in production — use a 2 sigma threshold or whatever the tool defaults to. Tell me if anything looks off."

"Are there any traffic anomalies flagged cluster-wide right now?"

6. Tear down shadow and revert​

"We’re done with the shadow test. Turn off traffic mirroring for api-service-route in production, put the ingress back on the weighted TraefikService so real split routing works again, and remove the mirror object."

Next Steps​