Activity: Shape Traffic with OpenShift Service Mesh

Module 2

Now that your services are locked down and secured, it’s time to focus on how traffic flows between them.

As a growing travel platform, the Travelz Corp team continuously rolls out new features and improvements to core services like discounts, which directly impact pricing and promotions. Because these changes affect customer experience and revenue, it’s crucial that updates are rolled out in a safe, observable, and reversible way.

You will leverage Red Hat OpenShift Service Mesh to shape and manage traffic flows using advanced techniques like Canary rollouts to gradually introduce new versions of a service. This allows teams to roll out changes safely and confidently, minimizing risk while gaining real-time observability and control.

Activity: Gradual Traffic Shifting with Weighted Routing

In this activity, you’ll simulate a real-world canary deployment strategy by introducing a new version of the discounts service (v2) and gradually shifting traffic to it.

Canary deployment is a strategy where a new version (the canary) is tested before all of the old instances are replaced

canary

In the next steps, you will create DestinationRule and VirtualService Istio resources. These resources control how traffic is routed between services, and are essential tools for canary deployment. They rely on the version label applied to service deployments to identify different versions of the services.

Create a DestinationRule

You will now define a DestinationRule for the discounts service with two version subsets: v1 and v2

A DestinationRule defines policies that apply to traffic directed to a service after routing has occurred. Version specific policies can be specified by defining a named subset

  1. Click the (+) button on the top navigation bar of {ocp_cluster_openshift_cluster_console_url}[OpenShift Console^, window="console"] to create a new resource.

    create yaml

  2. In the YAML editor, paste the following DestinationRule CR, and click the Create button.

    apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: discounts
  namespace: travel-agency
spec:
  host: discounts
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Apply the VirtualService

You will next create a VirtualService that initially sends 100% of traffic to v1, 0% to v2

A VirtualService defines a set of traffic routing rules that can route traffic based on subsets created by a DestinationRule.

  1. Click the (+) button on the top navigation bar of {ocp_cluster_openshift_cluster_console_url}[OpenShift Console^, window="console"] to create a new resource.

  2. In the YAML editor, copy the following VirtualService CR and click Create.

    apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: discounts
  namespace: travel-agency
spec:
  hosts:
    - discounts
  http:
  - route:
    - destination:
        host: discounts
        subset: v1
        port:
          number: 8000
      weight: 100
    - destination:
        host: discounts
        subset: v2
        port:
          number: 8000
      weight: 0

  3. This VirtualService currently routes 100% of traffic to version v1, since v2 is not yet deployed.

Deploy the discounts-v2 Service

You’ll deploy a second version of the discounts service (v2) into the mesh. It will run alongside the existing v1 version but won’t receive traffic until we configure routing.

  1. Click the (+) button on the top navigation bar of {ocp_cluster_openshift_cluster_console_url}[OpenShift Console^, window="console"] to create a new resource.

  2. In the YAML editor, copy the following Deployment CR and click Create.

    Note the version: v2 label attached to it under spec.selector.matchLabels in the YAML.

    kind: Deployment
apiVersion: apps/v1
metadata:
  name: discounts-v2
  namespace: travel-agency
spec:
  selector:
    matchLabels:
      app: discounts
      version: v2
  replicas: 1
  template:
    metadata:
      annotations:
        readiness.status.sidecar.istio.io/applicationPorts: ""
        proxy.istio.io/config: |
          tracing:
            zipkin:
              address: zipkin.istio-system:9411
            sampling: 10
            custom_tags:
              http.header.portal:
                header:
                  name: portal
              http.header.device:
                header:
                  name: device
              http.header.user:
                header:
                  name: user
              http.header.travel:
                header:
                  name: travel
      labels:
        app: discounts
        version: v2
    spec:
      containers:
        - name: discounts
          image: quay.io/kiali/demo_travels_discounts:v1
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8000
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
              - ALL
            privileged: false
            readOnlyRootFilesystem: true
          env:
            - name: CURRENT_SERVICE
              value: "discounts"
            - name: CURRENT_VERSION
              value: "v2"
            - name: LISTEN_ADDRESS
              value: ":8000"

  3. Wait for the deployment to scale to 1 pod successfully.

    discounts v2 deployment

    The version: v2 label in the discounts-v2 Deployment CRD is essential for enabling Istio’s traffic routing.