Traffic mirroring is also referred to as traffic shadowing. You can send a copy of live traffic to a mirrored service before you deploy your updates to production. This way, you can reduce risks when upgrading your apps by testing out the changes first.

For more information, see the following resources.

Before you begin

  1. Set up Gloo Mesh Gateway in a single cluster.
  2. Install Bookinfo and other sample apps.

  3. Configure an HTTP listener on your gateway and set up basic routing for the sample apps.

  4. In order to see the traffic mirroring, you must enable access logging on the remote reviews-v3 service in cluster2.

Configure mirror policies

You can apply a mirror policy at the route level. For more information, see Applying policies.

Review the following sample configuration file.

apiVersion: trafficcontrol.policy.gloo.solo.io/v2
kind: MirrorPolicy
metadata:
  name: mirror-policy
  namespace: bookinfo
spec:
  applyToRoutes:
  - route:
      labels:
        route: ratings
  config:
    destination:
      port:
        number: 9080
      ref:
        name: ratings
        namespace: bookinfo

Review the following table to understand this configuration. For more information, see the API docs.

SettingDescription
spec.applyToRoutesUse labels to configure which routes to apply the policy to. This example label matches the app and route from the example route table that you apply separately. If omitted and you do not have another selector such as applyToDestinations, the policy applies to all routes in the workspace.
spec.config.destination.portSpecify the port number in the service to mirror traffic to.
spec.config.destination.refSet the cluster, name, and namespace details for the service that you want to mirror traffic to.
spec.config.percentageSpecify the percentage of requests that you want to mirror to the service. The default is 100 to mirror all requests.

Verify mirror policies

Verify a mirror policy by checking for mirrored logs.

  1. Deploy another version (v2) of the ratings app. This app is used to verify that requests to the ratings v1 app are mirrored to the new ratings v2 app.

    kubectl apply -f - << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ratings-v2
  namespace: bookinfo
  labels:
    app: ratings
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ratings
      version: v2
  template:
    metadata:
      labels:
        app: ratings
        version: v2
    spec:
      serviceAccountName: bookinfo-ratings
      containers:
      - name: ratings
        image: docker.io/istio/examples-bookinfo-ratings-v1:1.17.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080
        securityContext:
          runAsUser: 1000
EOF

  2. Verify that the ratings v2 app is successfully deployed and shows a status of Running.

    kubectl get pods -n bookinfo

    Example output:

    NAME                              READY   STATUS    RESTARTS       AGE
details-v1-7d88846999-hzxcb       1/1     Running   0              6d16h
productpage-v1-7795568889-t4gsc   1/1     Running   0              6d16h
ratings-v1-754f9c4975-4cn57       1/1     Running   0              6d16h
ratings-v2-549cb4d9f9-4khvf       1/1     Running   0              42s
reviews-v1-5bf44ddc9f-kfnmp       1/1     Running   7 (132m ago)   5d22h
reviews-v2-6dcbdb99c7-x8rpn       1/1     Running   7 (132m ago)   5d22h

  3. Send a request to the ratings v1 app.

    • HTTP:
      curl -vik --resolve www.example.com:80:${INGRESS_GW_ADDRESS} http://www.example.com:80/ratings/1
    • HTTPS:
      curl -vik --resolve www.example.com:443:${INGRESS_GW_ADDRESS} https://www.example.com:443/ratings/1

    Example output:

    ...
< HTTP/2 200
HTTP/2 200
< content-type: application/json
...

  4. Verify that the request is logged for the ratings v1 app.

    kubectl logs -n bookinfo <ratings-v1-pod-name>

    Example output:

    Server listening on: http://0.0.0.0:9080
GET /ratings/1

  5. Verify that the request is not logged for the ratings v2 app.

    kubectl logs -n bookinfo <ratings-v2-pod-name>

    Example output:

    Server listening on: http://0.0.0.0:9080

  6. Apply the mirror policy for the ratings app. This mirror policy duplicates all traffic for one ratings app to all other ratings app instances in the cluster.

    kubectl apply -f - << EOF
apiVersion: trafficcontrol.policy.gloo.solo.io/v2
kind: MirrorPolicy
metadata:
  name: mirror-policy
  namespace: bookinfo
spec:
  applyToRoutes:
  - route:
      labels:
        route: ratings
  config:
    destination:
      port:
        number: 9080
      ref:
        name: ratings
        namespace: bookinfo
EOF

  7. Send another request to the ratings v1 app.

    • HTTP:
      curl -vik --resolve www.example.com:80:${INGRESS_GW_ADDRESS} http://www.example.com:80/ratings/1
    • HTTPS:
      curl -vik --resolve www.example.com:443:${INGRESS_GW_ADDRESS} https://www.example.com:443/ratings/1

  8. Verify that the request is logged for the ratings v1 app.

    kubectl logs <ratings-v1-pod-name> -n bookinfo

    Example output:

    Server listening on: http://0.0.0.0:9080
GET /ratings/1
GET /ratings/1

  9. Verify that the request is also logged for the ratings v2 app.

    kubectl logs <ratings-v2-pod-name> -n bookinfo

    Example output:

    Server listening on: http://0.0.0.0:9080
GET /ratings/1

Cleanup

You can optionally remove the resources that you set up as part of this guide.
kubectl delete deployment ratings-v2 -n bookinfo
kubectl delete mirrorpolicy mirror-policy -n bookinfo