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