Progressive Delivery with OpenShift GitOps Operator — Part 1
In this blog, I would like to introduce the concept of Progressive Delivery and talk about Argo Rollout features in detail how that adds value to standard kubernetes deployment strategies. Also, in the end we will see how OpenShift GitOps works with Argo Rollouts for Progressive Delivery approach.
Continuous Integration (CI) and Continuous Delivery (CD) have been widely adopted in modern software development enabling organizations to quickly deploy these software to customers. But doing it in the right way is equally important as in some cases unfinished code can lead to failures and customers have to face downtime. So to solve this, progressive delivery was introduced which enables the delivery of software with the right changes to the right amount of customers at the right time. More precisely, it controls the speed at which changes are deployed for a software.
Traditional CI/CD and Progressive Delivery
Continuous Integration (CI) is an automation process that helps in continuously integrating software development changes. It automates the building, testing, and validation of the source code. Its goal is to ultimately produce a packaged artifact that is ready to deploy.
Continuous Delivery (CD) helps in deploying software changes to users. It needs CI which produces an artifact that can be deployed to users. Hence, CI and CD are often used together.
But Continuous Delivery poses many challenges, such as handling fast delivery of changes, handling high-risk failures, to ensure uptime and efficient performance of the software. To solve the above problems of continuous delivery, progressive delivery comes into action along with different deployment strategies like blue-green deployment, canary deployment.
Progressive Delivery is one step ahead of Continuous Delivery. It enables delivering the software updates in a controlled manner by reducing the risks of failures. It is done by exposing the new changes of software to a smaller set of users, and then by observing and analyzing the correct behavior, it is then exposed to more users progressively. It is known to move fast but with control.
Before going directly into Progressive Delivery using OpenShift GitOps, lets understand the challenges with default kubernetes deployment and how Progressive Delivery potentially helps in providing some advanced deployment mechanisms.
Challenges with default “RollingUpdate” Kubernetes deployment Strategy
Kubernetes comes with a default RollingUpdate deployment strategy. At present, it has the following set of limitations:
- Fewer controls over speed of the rollout
- Inability to control traffic flow to the new version
- Readiness probes cannot be used for deeper, stress, or one-time checks
- You cannot query external metrics to verify an update
- You can halt the progression, but you cannot automatically abort and roll back the update
Argo Projects
Argo is a group of many open-source projects which help in the fast and safe delivery of software by extending the capabilities of Kubernetes.
- Argo Workflows: Container-native workflow engine
- Argo CD: Declarative GitOps continuous delivery
- Argo Events: Event-based dependency manager
- Argo Rollouts: Progressive delivery with support for Canary and blue-green deployment strategies
- Argoproj-labs: Separate GitHub org that is setup for community contributions related to the Argoproj ecosystem
To overcome the limitations of native Kubernetes deployment strategies, Argo Rollouts has been introduced and it contains below a different set of projects.
What is Argo Rollouts?
Argo Rollouts is a Kubernetes controller and a set of CRDs which provides progressive delivery features along with advanced deployments such as blue-green, canary, and canary analysis. It has the potential to control and shift traffic to a newer version of software through ingress controllers and service meshes.
The below table shows a comparative analysis of capabilities of the default Kubernetes deployment strategy vs. Argo Rollouts.
How does Argo Rollouts work?
The Argo Rollouts controller helps in finding and detecting the resource of a kind: Rollout in the cluster which manages the replicasets just like Kubernetes deployment does. It creates a stable replicaset for the older version of the software and a canary replicaset for the newer version of the software.
Source: Argo-Rollout-Architecture
The AnalysisTemplate helps in doing the analysis of the replicasets through the AnalysisRun component. Together, they help to observe the working of the newly deployed version. Accordingly, it can automatically roll out to a newer version or roll back it. For this one can use any metrics tool like Prometheus, Kubernetes jobs, and so on.
Progressive Delivery Using OpenShift GitOps
OpenShift GitOps uses Argo Rollouts to support Progressive Delivery.
The above picture describes the workflow of using progressive delivery with GitOps Operator.
Assuming GitOps Operator is already installed on the cluster, when a user submits RolloutsManager Custom Resource with required details to the GitOps operator, it will reconcile the custom resource and create the Argo Rollouts controller and supporting resources as shown in the picture.
RolloutsManager Specification
Users can specify the command arguments, environment variables, custom image name, e.t.c.,. for Argo Rollouts controller created by the operator using the `.spec` field in the RolloutsManager CR.
Complete details about the RolloutsManager CRD specification with examples can be found here.
Installation
Prerequisite
- OpenShift GitOps operator is installed.
Switch to the project where you want to use OpenShift GitOps for progressive delivery.
For example, default project
Click on Red Hat OpenShift GitOps
Make sure the installed version is >= v1.9.0 as progressive delivery is not supported before v1.9.0
In the Provided APIs section, click on Create Instance in RolloutManager
In the YAML view, either use the default YAML or replace it with one of the examples provided in Docs.
The basic example of RolloutManager CR is to install Argo Rollouts and it’s resources with default values for progressive delivery is
Verify Installation
Wait for the Status field of the RolloutManagers instance change to phase: Available
Verify creation of resources
- Under the Workloads tab, verify that deployment with name argo-rollouts is available with status 1 of 1 pods (pod is running).
- Under the Networking tab, verify that a service with name argo-rollouts-metrics is created.
- Under the Workloads tab, Verify that a secret with name argo-rollouts-notification-secret is created.
- Under the User Management tab, In Roles, verify that the following roles are created.
- argo-rollout (Role)
- argo-rollouts-aggregate-to-admin (ClusterRole)
- argo-rollouts-aggregate-to-edit (ClusterRole)
- argo-rollouts-aggregate-to-view (ClusterRole)
- argo-rollouts-manager-metrics-reader (ClusterRole)
- Under the User Management tab, In RoleBindings, verify that a role binding named argo-rollouts are created.
Conclusion
In this article, we discussed what progressive delivery is all about and its characteristics. We also learned about how Argo Rollouts can be configured using OpenShift GitOps with the use of Argo RolloutsManager Custom Resource to create the Argo Rollouts Controller.
What’s next? Now that we have developed an understanding of progressive delivery and how this is supported from OpenShift GitOps, next would be to try some deployment strategies such as blue-green deployments, canary deployments using Argo Rollouts feature in OpenShift GitOps.
