Getting Started with Gloo Gateway and Argo Rollouts
January 31, 2024
Alex Ly
As I mentioned in my last post, which was about Gloo Mesh and Argo Rollouts, enabling applications to seamlessly transition from one version to another is critical for both organizations and users.
In addition to Gloo Mesh, we’ve also integrated Argo Rollouts into Gloo Gateway, combining Argo Rollouts’ traffic management capabilities with Gloo Gateway’s advanced routing mechanisms through a supported plugin.
Note: Gloo Edge, which I’ll refer to in this guide for setting up the integration, continues to be fully supported, but has been consolidated into Gloo Gateway.
Prerequisites
Before we get started, make sure you have a Kubernetes cluster deployed.
You can also run glooctl check to perform a quick health check.
% glooctl check
Checking deployments... OK
Checking pods... OK
Checking upstreams... OK
Checking upstream groups... OK
Checking auth configs... OK
Checking rate limit configs... OK
Checking VirtualHostOptions... OK
Checking RouteOptions... OK
Checking secrets... OK
Checking virtual services... OK
Checking gateways... OK
Checking proxies... OK
No problems detected.
Skipping Gloo Instance check -- Gloo Federation not detected
Review Blue-green Rollout Strategy
A Blue Green Deployment allows users to reduce the amount of time multiple versions running at the same time. This means that in a blue/green rollout that the traffic will be shifted from blue > green as soon as the green application is ready to take on traffic if autoPromotionEnabled: true. Additionally, a user can set the following Configurable Features listed on the upstream docs such as autoPromotionSeconds: 20, for example.
Something to note about this strategy is that besides providing connectivity from the gateway to the application, there is no traffic shifting happening from the gateway perspective moving from blue > green. The example below uses the default Argo Rollouts blue/green strategy which controls K8s services, and not Gloo Edge routes. See Sequence of Events for more details on this strategy.
Blue-green Rollout Diagram
Deploy and Configure the Initial Rollout
Deploy the rollouts-demo application. The following rollout has autoPromotionEnabled: false to demonstrate a manual promotion process.
A Canary rollout is a deployment strategy where the operator releases a new version of their application to a small percentage of the production traffic. We can use weights, pause durations, and manual promotion in order to control how our application is rolled out across the stable and canary services.
Similar to the above Blue/Green strategy, the Argo Rollouts Canary strategy supports the K8s API directly basic example here, as well as many examples of integrations for Traffic Management that allow more advanced rollout scenarios.
The example below uses the Canary strategy, implemented by the Gloo Edge Argo Rollouts Plugin. This plugin allows Argo Rollouts to manage Gloo Edge objects such as Upstream, VirtualService, and RouteTable.
In the Rollout config, we will configure the plugin integration with Gloo Edge by defining a trafficRouting.plugin.solo-io/glooedge.
In the rollouts demo UI we should be able to see the steps and the respective weights pretty clearly in the shift from blue to green.
Bonus:
If you set the Rollout strategy steps as follows, the promotion will happen automatically every 5 seconds except for the second step (at 25%) which requires a manual promotion.
When doing so, you can also run a -w watch command on the following resources to visualize the config changes being managed by the Rollouts controller which are described in the diagrams at the top of this section.
kubectl get svc rollouts-demo-active -n rollouts-demo -oyaml -w
kubectl get svc rollouts-demo-preview -n rollouts-demo -oyaml -w
kubectl get routetable rollouts-demo-routes -n gloo-system -oyaml -w
In the rollouts demo UI we should be able to see that the rollout pauses at the 25% weight until promoted, with the rest of the rollout automatically promoted after a 5 second duration between steps.
Analysis Runs
As a part of the Rollout, analysis can be run in the background — while the canary is progressing through its rollout steps.
An AnalysisTemplate is a template spec which defines how to perform a canary analysis, such as the metrics which it should perform, its frequency, and the values which are considered successful or failed. AnalysisTemplates may be parameterized with inputs values.
Here are two very simple AnalysisTemplate examples to mimic two behaviors pass and always-fail.
kubectl apply -f- <<EOF
# This AnalysisTemplate will run a Kubernetes Job every 5 seconds that succeeds.
kind: AnalysisTemplate
apiVersion: argoproj.io/v1alpha1
metadata:
name: pass
namespace: rollouts-demo
spec:
metrics:
- name: pass
count: 1
interval: 5s
failureLimit: 1
provider:
job:
spec:
template:
spec:
containers:
- name: sleep
image: alpine:3.8
command: [sh, -c]
args: [exit 0]
restartPolicy: Never
backoffLimit: 0
---
# This AnalysisTemplate will run a Kubernetes Job every 5 seconds, with a 50% chance of failure.
# When the number of accumulated failures exceeds failureLimit, it will cause the analysis run to
# fail, and subsequently cause the rollout or experiment to abort.
kind: AnalysisTemplate
apiVersion: argoproj.io/v1alpha1
metadata:
name: always-fail
namespace: rollouts-demo
spec:
metrics:
- name: always-fail
count: 2
interval: 5s
failureLimit: 1
provider:
job:
spec:
template:
spec:
containers:
- name: sleep
image: alpine:3.8
command: [exit 0]
args: [exit 0]
restartPolicy: Never
backoffLimit: 0
EOF
Now we can add an strategy.canary.steps.analysis config to our Rollout.
Now let’s repeat the experiment and change the image again to another color such as back to blue, or even yellow.
kubectl argo rollouts set image rollouts-demo -n rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow
If you check the rollout status again, this time we will see the added AnalysisRun step shows that it was ✔ Successful which means that during the rollout the analysis was triggered and passed.
kubectl argo rollouts get rollout rollouts-demo -n rollouts-demo
Bonus Exercise: Always Fail
Try it again, but this time use the always-fail AnalysisTemplate to observe a rollback operation. Note that by using startingStep: 3 that the always-fail analysistemplate will be run as step 3 starts begins, and then will roll back.
You can visualize the rollout and rollback in the UI.
Note that it is possible to nest an analysis step inside of a setWeight step, such as in the example below, where analysis runs happen on steps 10% and 50%. Doing so will allow you to add additional config such as args to your analysis.
This tutorial demonstrates the ease of integrating progressive delivery workflows to your application deployments using Argo Rollouts and Gloo Gateway with Edge, but it only scratches the surface! Many standard options exist in the Argo Rollouts Documentation such as BlueGreen Deployment Strategy and Canary Strategy. Take a look at other strategies and routing examples in the plugin github repo examples as well as the Analysis & Progressive Delivery documentation for more ways to get started.
