Chapter 4. Routing traffic by using Argo Rollouts You can progressively route a subset of user traffic to a new application version by using Argo Rollouts and its traffic-splitting mechanisms. Then you can test whether the application is deployed and working. With Openshift Routes, you can configure Argo Rollouts to reduce or increase the amount of traffic by directing it to various applications in a cluster environment based on your requirements. You can use OpenShift Routes to split traffic between two application versions: Canary version : A new version of an application where you gradually route the traffic. Stable version : The current version of an application. After the canary version is stable and has all the user traffic directed to it, it becomes the new stable version. The stable version is discarded. 4.1. Prerequisites You have logged in to the OpenShift Container Platform cluster as an administrator. You have installed Red Hat OpenShift GitOps on your OpenShift Container Platform cluster. You have installed Argo Rollouts on your OpenShift Container Platform cluster. You have installed the Red Hat OpenShift GitOps CLI on your system. You have installed the Argo Rollouts CLI on your system. 4.2. Configuring Argo Rollouts to route traffic by using OpenShift Routes You can use OpenShift Routes to configure Argo Rollouts to create routes, rollouts, and services. The following example procedure creates a route, a rollout, and two services. It then gradually routes an increasing percentage of traffic to a canary version of the application before that canary state is marked as successful and becomes the new stable version. Prerequisites You have logged in to the OpenShift Container Platform cluster as an administrator. You have installed the Red Hat OpenShift GitOps on your OpenShift Container Platform cluster. You have installed Argo Rollouts on your OpenShift Container Platform cluster. For more information, see "Creating a RolloutManager custom resource". You have installed the Red Hat OpenShift GitOps CLI on your system. For more information, see "Installing the GitOps CLI". You have installed the Argo Rollouts CLI on your system. For more information, see "Argo Rollouts CLI overview". Procedure Create a Route object. In the Administrator perspective of the web console, click Networking Routes . Click Create Route . On the Create Route page, click YAML view and add the following snippet: The following example creates a route called rollouts-demo-route : apiVersion: route.openshift.io/v1 kind: Route metadata: name: rollouts-demo-route spec: port: targetPort: http 1 tls: 2 insecureEdgeTerminationPolicy: Redirect termination: edge to: kind: Service name: argo-rollouts-stable-service 3 weight: 100 4 alternateBackends: - kind: Service name: argo-rollouts-canary-service 5 weight: 0 6 1 Specifies the name of the port used by the application for running inside the container. 2 Specifies the TLS configuration used to secure the route. 3 The name of the targeted stable service. 4 This field is automatically modified to stable weight by Route Rollout plugin. 5 The name of the targeted canary service. 6 This field is automatically modified to canary weight by Route Rollout plugin. Click Create to create the route. It is then displayed on the Routes page. Create the services, canary and stable, to be referenced in the route. In the Administrator perspective of the web console, click Networking Services . Click Create Service . On the Create Service page, click YAML view and add the following snippet: The following example creates a canary service called argo-rollouts-canary-service . Canary traffic is directed to this service. apiVersion: v1 kind: Service metadata: name: argo-rollouts-canary-service spec: ports: 1 - port: 80 targetPort: http protocol: TCP name: http selector: 2 app: rollouts-demo 1 Specifies the name of the port used by the application for running inside the container. 2 Ensure that the contents of the selector field are the same as in stable service and Rollout custom resource (CR). Important Ensure that the name of the canary service specified in the Route object matches with the name of the canary service specified in the Service object. Click Create to create the canary service. Rollouts automatically update the created service with pod template hash of the canary ReplicaSet . For example, rollouts-pod-template-hash: 7bf84f9696 . Repeat these steps to create the stable service: The following example creates a stable service called argo-rollouts-stable-service . Stable traffic is directed to this service. apiVersion: v1 kind: Service metadata: name: argo-rollouts-stable-service spec: ports: 1 - port: 80 targetPort: http protocol: TCP name: http selector: 2 app: rollouts-demo 1 Specifies the name of the port used by the application for running inside the container. 2 Ensure that the contents of the selector field are the same as in canary service and Rollout CR . Important Ensure that the name of the stable service specified in the Route object matches with the name of the stable service specified in the Service object. Click Create to create the stable service. Rollouts automatically update the created service with pod template hash of the stable ReplicaSet . For example, rollouts-pod-template-hash: 1b6a7733 . Create the Rollout CR to reference the Route and Service objects. In the Administrator perspective of the web console, go to Operators Installed Operators Red Hat OpenShift GitOps Rollout . On the Create Rollout page, click YAML view and add the following snippet: The following example creates a Rollout CR called rollouts-demo : apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: rollouts-demo spec: template: 1 metadata: labels: app: rollouts-demo spec: containers: - name: rollouts-demo image: argoproj/rollouts-demo:blue ports: - name: http containerPort: 8080 protocol: TCP resources: requests: memory: 32Mi cpu: 5m revisionHistoryLimit: 2 replicas: 5 strategy: canary: canaryService: argo-rollouts-canary-service 2 stableService: argo-rollouts-stable-service 3 trafficRouting: plugins: argoproj-labs/openshift: routes: - rollouts-demo-route 4 steps: 5 - setWeight: 30 - pause: {} - setWeight: 60 - pause: {} selector: 6 matchLabels: app: rollouts-demo 1 Specifies the pods that are to be created. 2 This value must match the name of the created canary Service . 3 This value must match the name of the created stable Service . 4 This value must match the name of the created Route CR. 5 Specify the steps for the rollout. This example gradually routes 30%, 60%, and 100% of traffic to the canary version. 6 Ensure that the contents of the selector field are the same as in canary and stable service. Click Create . In the Rollout tab, under the Rollout section, verify that the Status field of the rollout shows Phase: Healthy . Verify that the route is directing 100% of the traffic towards the stable version of the application. Note When the first instance of the Rollout resource is created, the rollout regulates the amount of traffic to be directed towards the stable and canary application versions. In the initial instance, the creation of the Rollout resource routes all of the traffic towards the stable version of the application and skips the part where the traffic is sent to the canary version. Go to Networking Routes and look for the Route resource you want to verify. Select the YAML tab and view the following snippet: Example: Route kind: Route metadata: name: rollouts-demo-route spec: alternateBackends: - kind: Service name: argo-rollouts-canary-service weight: 0 1 # (...) to: kind: Service name: argo-rollouts-stable-service weight: 100 2 1 A value of 0 means that 0% of traffic is directed to the canary version. 2 A value of 100 means that 100% of traffic is directed to the stable version. Simulate the new canary version of the application by modifying the container image deployed in the rollout. In the Administrator perspective of the web console, go to Operators Installed Operators Red Hat OpenShift GitOps Rollout . Select the existing Rollout and modify the .spec.template.spec.containers.image value from argoproj/rollouts-demo:blue to argoproj/rollouts-demo:yellow . As a result, the container image deployed in the rollout is modified and the rollout initiates a new canary deployment. Note As per the setWeight property defined in the .spec.strategy.canary.steps field of the Rollout resource, initially 30% of traffic to the route reaches the canary version and 70% of traffic is directed towards the stable version. The rollout is paused after 30% of traffic is directed to the canary version. Example route with 30% of traffic directed to the canary version and 70% directed to the stable version. spec: alternateBackends: - kind: Service name: argo-rollouts-canary-service weight: 30 # (...) to: kind: Service name: argo-rollouts-stable-service weight: 70 Simulate another new canary version of the application by running the following command in the Argo Rollouts CLI: USD oc argo rollouts promote rollouts-demo -n <namespace> 1 1 Specify the namespace where the Rollout resource is defined. This increases the traffic weight to 60% in the canary version and 40% in the stable version. Example route with 60% of traffic directed to the canary version and 40% directed to the stable version. spec: alternateBackends: - kind: Service name: argo-rollouts-canary-service weight: 60 # (...) to: kind: Service name: argo-rollouts-stable-service weight: 40 Increase the traffic weight in the canary version to 100% and discard the traffic in the old stable version of the application by running the following command: USD oc argo rollouts promote rollouts-demo -n <namespace> 1 1 Specify the namespace where the Rollout resource is defined. Example route with 0% of traffic directed to the canary version and 100% directed to the stable version. spec: # (...) to: kind: Service name: argo-rollouts-stable-service weight: 100 4.3. Additional resources Configuring the GitOps CLI Argo Rollouts CLI overview Argo Rollouts tech preview limitations

Commands:
apiVersion: route.openshift.io/v1 kind: Route metadata: name: rollouts-demo-route spec: port: targetPort: http 1 tls: 2 insecureEdgeTerminationPolicy: Redirect termination: edge to: kind: Service name: argo-rollouts-stable-service 3 weight: 100 4 alternateBackends: - kind: Service name: argo-rollouts-canary-service 5 weight: 0 6
apiVersion: v1 kind: Service metadata: name: argo-rollouts-canary-service spec: ports: 1 - port: 80 targetPort: http protocol: TCP name: http selector: 2 app: rollouts-demo
apiVersion: v1 kind: Service metadata: name: argo-rollouts-stable-service spec: ports: 1 - port: 80 targetPort: http protocol: TCP name: http selector: 2 app: rollouts-demo
apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: rollouts-demo spec: template: 1 metadata: labels: app: rollouts-demo spec: containers: - name: rollouts-demo image: argoproj/rollouts-demo:blue ports: - name: http containerPort: 8080 protocol: TCP resources: requests: memory: 32Mi cpu: 5m revisionHistoryLimit: 2 replicas: 5 strategy: canary: canaryService: argo-rollouts-canary-service 2 stableService: argo-rollouts-stable-service 3 trafficRouting: plugins: argoproj-labs/openshift: routes: - rollouts-demo-route 4 steps: 5 - setWeight: 30 - pause: {} - setWeight: 60 - pause: {} selector: 6 matchLabels: app: rollouts-demo
kind: Route metadata: name: rollouts-demo-route spec: alternateBackends: - kind: Service name: argo-rollouts-canary-service weight: 0 1 # (...) to: kind: Service name: argo-rollouts-stable-service weight: 100 2
spec: alternateBackends: - kind: Service name: argo-rollouts-canary-service weight: 30 # (...) to: kind: Service name: argo-rollouts-stable-service weight: 70
oc argo rollouts promote rollouts-demo -n <namespace> 1
spec: alternateBackends: - kind: Service name: argo-rollouts-canary-service weight: 60 # (...) to: kind: Service name: argo-rollouts-stable-service weight: 40
oc argo rollouts promote rollouts-demo -n <namespace> 1
spec: # (...) to: kind: Service name: argo-rollouts-stable-service weight: 100