Questo contenuto non è disponibile nella lingua selezionata.
Chapter 5. Routing traffic by using Argo Rollouts for OpenShift Service Mesh
Argo Rollouts in Red Hat OpenShift GitOps support various traffic management mechanisms such as OpenShift Routes and Istio-based OpenShift Service Mesh.
The choice for selecting a traffic manager to be used with Argo Rollouts depends on the existing traffic management solution that you are using to deploy cluster workloads. For example, Red Hat OpenShift Routes provides basic traffic management functionality and does not require the use of a sidecar container. However, Red Hat OpenShift Service Mesh provides more advanced routing capabilities by using Istio but does require the configuration of a sidecar container.
You can use OpenShift Service Mesh 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 previous stable version is discarded.
The Istio-support within Argo Rollouts uses the Gateway and VirtualService resources to handle traffic routing.
- Gateway: You can use a Gateway to manage inbound and outbound traffic for your mesh. The gateway is the entry point of OpenShift Service Mesh and handles traffic requests sent to an application.
- VirtualService: VirtualService defines traffic routing rules and the percentage of traffic that goes to underlying services, such as the stable and canary services.
Sample deployment scenario
For example, in a sample deployment scenario, 100% of the traffic is directed towards the stable version of the application during the initial instance. The application is running as expected, and no additional attempts are made to deploy a new version.
However, after deploying a new version of the application, Argo Rollouts creates a new canary deployment based on the new version of the application and routes some percentage of traffic to that new version.
When you use Service Mesh, Argo Rollouts automatically modifies the VirtualService resource to control the traffic split percentage between the stable and canary application versions. In the following diagram, 20% of traffic is sent to the canary application version after the first promotion and then 80% is sent to the stable version by the stable service.
5.1. Configuring Argo Rollouts to route traffic by using OpenShift Service Mesh Copia collegamentoCollegamento copiato negli appunti!
You can use OpenShift Service Mesh to configure Argo Rollouts by creating the following items:
- A gateway
- Two Kubernetes services: stable and canary, which point to the pods within each version of the services
- A VirtualService
- A rollout custom resource (CR)
In the following example procedure, the rollout routes 20% of traffic to a canary version of the application. After a manual promotion, the rollout routes 40% of traffic. After another manual promotion, the rollout performs multiple automated promotions until all traffic is routed to the new application version.
Prerequisites
- You are logged in to the OpenShift Container Platform cluster as an administrator.
- You installed Red Hat OpenShift GitOps on your OpenShift Container Platform cluster.
- You installed Argo Rollouts on your OpenShift Container Platform cluster.
- You installed the Argo Rollouts CLI on your system.
- You installed the OpenShift Service Mesh operator on the cluster and configured the ServiceMeshControlPlane.
Procedure
Create a
Gateway
object to accept the inbound traffic for your mesh.Create a YAML file with the following snippet content.
Example gateway called
rollouts-demo-gateway
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the YAML file by running the following command.
oc apply -f gateway.yaml
$ oc apply -f gateway.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Create the services for the canary and stable versions of the application.
-
In the Administrator perspective of the web console, go to Networking
Services. - Click Create Service.
On the Create Service page, click YAML view and add the following snippet. The following example creates a stable service called
rollouts-demo-stable
. Stable traffic is directed to this service.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Create to create a stable service.
On the Create Service page, click YAML view and add the following snippet. The following example creates a canary service called
rollouts-demo-canary
. Canary traffic is directed to this service.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Create to create the canary service.
-
In the Administrator perspective of the web console, go to Networking
Create a VirtualService to route incoming traffic to stable and canary services.
Create a YAML file, and copy the following YAML into it. The following example creates a
VirtualService
calledrollouts-demo-vsvc
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the YAML file by running the following command.
oc apply -f virtual-service.yaml
$ oc apply -f virtual-service.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Create the
Rollout
CR. In this example,Istio
is used as a traffic manager.-
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 calledrollouts-demo
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- This value must match the name of the created canary
Service
. - 2
- This value must match the name of the created stable
Service
. - 3
- Specify the steps for the rollout. This example gradually routes 20%, 40%, 60%, and 100% of traffic to the canary version.
- 4
- 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.
-
In the Administrator perspective of the web console, go to Operators
Verify that the route is directing 100% of the traffic towards the stable version of the application.
Watch the progression of your rollout by running the following command:
oc argo rollouts get rollout rollouts-demo --watch -n <namespace>
$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the namespace where the
Rollout
resource is defined.
Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteWhen 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 theRollout
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.To verify that the service mesh sends 100% of the traffic for the stable service and 0% for the canary service, run the following command:
oc describe virtualservice/rollouts-demo-vsvc -n <namespace>
$ oc describe virtualservice/rollouts-demo-vsvc -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow View the following output displayed in the terminal:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Simulate the new canary version of the application by modifying the container image deployed in the rollout.
Modify the
.spec.template.spec.containers.image
value fromargoproj/rollouts-demo:blue
toargoproj/rollouts-demo:yellow
, by running the following command.oc argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow -n <namespace>
$ oc argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow As a result, the container image deployed in the rollout is modified and the rollout initiates a new canary deployment.
NoteAs per the
setWeight
property defined in the.spec.strategy.canary.steps
field of theRollout
resource, initially 20% of traffic to the route reaches the canary version and 80% of traffic is directed towards the stable version. The rollout is paused after 20% of traffic is directed to the canary version.Watch the progression of your rollout by running the following command.
oc argo rollouts get rollout rollouts-demo --watch -n <namespace>
$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the namespace where the
Rollout
resource is defined.
In the following example, 80% of traffic is routed to the stable service and 20% of traffic is routed to the canary service. The deployment is then paused indefinitely until you manually promote it to the next level.
Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example with 80% directed to the stable version and 20% of traffic directed to the canary version.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Manually promote the deployment to the next promotion step.
oc argo rollouts promote rollouts-demo -n <namespace>
$ oc argo rollouts promote rollouts-demo -n <namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the namespace where the
Rollout
resource is defined.
Watch the progression of your rollout by running the following command:
oc argo rollouts get rollout rollouts-demo --watch -n <namespace>
$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the namespace where the
Rollout
resource is defined.
In the following example, 60% of traffic is routed to the stable service and 40% of traffic is routed to the canary service. The deployment is then paused indefinitely until you manually promote it to the next level.
Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example of 60% traffic directed to the stable version and 40% directed to the canary version.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Increase the traffic weight in the canary version to 100% and discard the traffic in the previous stable version of the application by running the following command:
oc argo rollouts promote rollouts-demo -n <namespace>
$ oc argo rollouts promote rollouts-demo -n <namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the namespace where the
Rollout
resource is defined.
Watch the progression of your rollout by running the following command:
oc argo rollouts get rollout rollouts-demo --watch -n <namespace>
$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the namespace where the
Rollout
resource is defined.
After successful completion, weight on the stable service is 100% and 0% on the canary service.