Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

Before configuring mirroring in Istio, it helps to understand common release strategies and how mirroring fits between them.

​
Release strategies: Canary vs Blue–Green

A canary release introduces a new version gradually. The majority of users continue to use the stable v1 application while a small percentage is routed to the new version (v2). This limits blast radius while exposing the new version to real traffic.
An infographic titled "Canary Release" showing a Kubernetes namespace where an Ingress Gateway routes 90% of traffic to Deployment V1 and 10% to Deployment V2, with services, replica sets, pods, and containers illustrated. The diagram visualizes how a new version is gradually introduced.
You can adjust the routed percentage (for example 90/10, 95/5, etc.), but the defining trait of canary is the gradual traffic split. Blue–green releases, by contrast, switch all user traffic from v1 to v2 in a single cutover. There is no gradual ramp — users are on v1 one moment and v2 the next.
A diagram titled "Blue/Green Release" showing a Kubernetes namespace where an Ingress Gateway routes user traffic to a Service, which forwards to two deployments (V1 and V2) with replica sets and multiple pods/containers.
Both approaches have trade-offs. Use the table below to compare them quickly.
StrategyRollout patternRisk exposureBest for
CanaryGradual traffic ramp (percent-based)Low exposure early; increases as ramp proceedsSafely validate behavior with a subset of users
Blue–GreenAll-or-nothing cutoverFull exposure at switch; fast rollback possibleQuick, atomic switch when environments are ready
Ideally you want the low-risk validation of a canary with the ability to test the new version against full production traffic. Istio’s traffic mirroring helps you achieve that combination.

​
What is Istio traffic mirroring?

Istio traffic mirroring sends a copy of live production requests to another version of your service (for example, a staging or test instance) while the original response still goes to production. Mirroring lets you exercise v2 with real requests and production payloads without affecting user-visible responses.
Diagram of traffic mirroring in Kubernetes: users send requests via an Ingress Gateway to a Service inside a Namespace. The Service routes traffic to two deployments (V1 and V2) showing replica sets, pods and containers.
Key points:
  • Mirrored requests are copies — responses from the mirrored destination are ignored by Istio and never returned to the client.
  • Mirroring is asynchronous and safe for exercising read-only behavior and performance testing.
  • Avoid side effects (for example, writes to production databases) from mirrored requests unless you have safeguards (see the warning below).
Mirrored traffic still reaches the mirrored service. If that service performs writes (to databases, external APIs, or modifies shared state), those side-effects will occur unless explicitly isolated. Always ensure mirrored requests are safe or routed to an isolated environment to avoid corrupting production data.

​
Deployments and Service setup

To enable mirroring you need two versions of your application deployed — for example v1 (production) and v2 (mirror/test). Both deployments can share the same Service selector (e.g., app: frontend) so that Istio can route to subsets defined by a DestinationRule. Example Kubernetes Deployment and Service manifests: 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-v2-deployment
  namespace: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
      version: v2
  template:
    metadata:
      labels:
        app: frontend
        version: v2
    spec:
      containers:
      - name: app
        image: app:2.1
---
apiVersion: v1
kind: Service
metadata:
  name: app-svc
  namespace: frontend
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: frontend
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-v1-deployment
  namespace: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
      version: v1
  template:
    metadata:
      labels:
        app: frontend
        version: v1
    spec:
      containers:
      - name: app
        image: app:1.1
Note:
  • The Service app-svc selects pods with app: frontend. Subsets (v1, v2) are distinguished by the version label and defined in a DestinationRule.

​
VirtualService and DestinationRule for mirroring

Mirroring is configured in an Istio VirtualService by adding a mirror destination to the primary route. The mirrored subset(s) are declared in a matching DestinationRule. Example VirtualService and DestinationRule that implement mirroring: 
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: app-vs
  namespace: frontend
spec:
  hosts:
  - app-svc
  http:
  - route:
    - destination:
        host: app-svc
        port:
          number: 80
        subset: v1
      weight: 100
    mirror:
      host: app-svc
      port:
        number: 80
      subset: v2
    mirrorPercent: 100
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: app-ds
  namespace: frontend
spec:
  host: app-svc
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
In this setup:
  • The route section sends all user-facing requests to subset v1.
  • The mirror section sends a copy of each request to subset v2.
  • mirrorPercent controls the fraction of requests that are mirrored (0–100). Use lower values to sample mirrored traffic.
Mirrored requests are sent asynchronously to the mirror destination; responses from the mirrored service are ignored by Istio and not returned to the user. Mirroring is therefore safe for exercising behavior but should not be used for anything that affects observable user state (e.g., writing to production databases) unless you take appropriate safeguards.

​
Why use mirroring?

A presentation slide titled "Why Use Mirroring?" with a vertical, color-coded list of five benefits. Each numbered item (with small icons) mentions testing new service versions in production, identifying issues early, zero impact on users, safe switching after validation, and gaining performance/debugging insights.
Mirroring provides several practical benefits:
  • Validate new service versions with real production traffic without impacting users.
  • Discover issues earlier using live workloads and production payloads.
  • Maintain zero user impact because mirrored responses are discarded.
  • Confidently verify v2 behavior before a full cutover or canary ramp.
  • Collect realistic performance metrics and debugging traces under production load.

​
Mirroring configuration options

Istio supports a few mirroring options you should know about:
  • mirror destination: specifies host/port/subset to receive mirrored requests.
  • mirrorPercent: sample rate for mirrored traffic (0–100).
  • PortSelector: explicitly choose a target port for mirrored traffic.
  • HTTPMirrorPolicy fields available on the VirtualService HTTP route.
A documentation-style slide titled "Mirroring Options" showing HTTPMirrorPolicy, PortSelector and Percent sections with tables and a right-hand HTTPRoute reference panel. It includes a KodeKloud copyright and a link to the istio.io docs.
For the most up-to-date API and fields, see the Istio VirtualService documentation:

​
Quick checklist to enable mirroring

  1. Deploy production version (v1) and the mirrored/test version (v2).
  2. Ensure both deployments share the Service selector (for example app: frontend).
  3. Create a DestinationRule with subsets matching the version labels.
  4. Create or update the VirtualService: route primary traffic to v1, set mirror to v2, and adjust mirrorPercent.
  5. Monitor mirrored service logs, traces, and metrics to validate behavior.
  6. Gradually increase mirrorPercent if you need more sampling before a full rollout.

​
Best practices

  • Use mirroring for read-only validation, performance testing, and debugging.
  • Isolate mirrored environments from production stateful systems (databases, billing systems) to prevent accidental writes.
  • Start with a small mirrorPercent (for example 1–5%) when traffic volume is high to limit load.
  • Combine mirroring with tracing and logging so you can correlate production and mirrored requests.
  • Clean up or scale down mirrored deployments when validation is complete.
References

Watch Video