How Helm Subcharts Make the Transition to Argo Rollouts a Breeze

As your Kubernetes-based application grows, so does the complexity of managing its deployment and rollout. Argo Rollouts, a part of the Cloud Native Computing Foundation (CNCF), is a popular tool for managing canary deployments, blue-green deployments, and other advanced deployment strategies on Kubernetes.

This blog post will show our preferred way of migrating services from Deployment to Rollout using Argo Rollouts in high-scale complicated service architectures.

As a DevOps Application Team (The Enablers), our goal is to enable the seamless deployment and management of multi-tenant services at scale within our organization. We help, guide, and provide best practices on our SaaS deployments to service owners who own micro-services. Our goal is to provide solutions that are easy to use and can scale up to meet the organization’s needs.

Why use Argo Rollouts for Kubernetes Deployments 

Before we dive into the technical details of the migration process, let’s briefly review the benefits:

• Canary releases: Argo Rollouts allows you to roll out new versions of your application, gradually, testing them with a small percentage of users before deploying them to everyone. This minimizes the risk of introducing bugs or performance issues.
• Blue-green deployments: Argo Rollouts enables you to deploy multiple versions of your application in parallel, routing traffic to the new version only after it passes certain health checks. This allows you to quickly roll back to the previous version if the new version has issues.
• Rollback and promotion: Argo Rollouts allows you to easily roll back to a previous version of your application if there are issues with the current version. You can also promote a canary deployment to a stable deployment with a single command.

Migrating to Argo Rollouts: Two Paths

We followed the official documentation for migrating to Argo Rollouts and found out that such a migration involves changing an existing ‘Deployment’ type to ‘Rollout’ type, in two  ways:

1. Overriding an existing Deployment with Rollout
2. Pointing the new Rollout object to an existing Deployment

Migration path #1: Overriding an existing Deployment Rollout

Challenges of the first approach: 

• It involves overriding the service owner’s chart Kubernetes objects; this approach can be complex and error-prone, especially when dealing with multiple service owners that have their own deployment configuration and chart.
• The service owner is unaware of the Rollout CRD created by Argo Rollouts.
• Once overridden, it’s not easy to rollback to the Deployment (not feature flagged).
• Conceptually, it would be very hard to migrate hundreds of services in this way, and we cannot control one source of truth for all rollout objects like analysis templates, etc.

Migration path #2: Pointing the Rollout Object to an Existing Deployment

Migrating to Argo Rollouts using Subcharts

Helm Subcharts allow you to break down a large chart into smaller, reusable components. By using subcharts, you can point the new Rollout object to the existing deployment without interfering with the existing chart.

Finally, we’ve decided to try out the second approach of pointing the existing rollout to a deployment object rather than overriding the existing chart. We found it much easier, but then we still didn’t want to add new Kubernetes objects directly to the service owner’s chart.

As “The Enablers,” our DevOps Application team aimed to find a more sophisticated approach that would grant us global ownership over the chart, while also enabling us to onboard service owners to Argo Rollouts quickly. However, we wanted to ensure that there was enough flexibility for service owners to write their own canary/blue-green processes. After brainstorming, we came up with the idea of creating a Helm subchart that would only include the necessary rollout objects. This approach strikes a balance between ownership, flexibility, and ease of onboarding.

In this approach, the DevOps Application Team is maintaining a centralized Helm chart that can be potentially used by all service owners and holds all related Argo Rollouts CRDs.

This exposes the Rollout object based on a name of an existing deployment (via values.yaml), and the necessary configuration for implementing the canary/blue-green steps. Extra support for objects like HPA can easily be supported in such an approach, as well as out-of-the-box AnalysisTemplates that can serve as generic guidelines and best practices provided by the DevOps Application Team (“the enablers”).

Onboarding is involved with inheriting the sub chart and providing the right values.yaml based on the chart’s templating values:

dependencies:
- name: jfrog-argo-rollouts
  version: 1.0.0
  repository: https://argo.jfrog.io/artifactory/helm
  condition: argorollouts.enabled

Note: Ingress and Service objects should still be implemented in the service owner’s chart anyways as a better practice.

This approach has several advantages:

• Easier for service owners: Service owners only need to add the “jfrog-argo rollouts” as a subchart that contains the Rollout object to their existing chart. They don’t need to understand the details of how the Rollout object works or modify the existing chart.
• Easier for DevOps: DevOps teams can manage the Rollout object as a separate subchart, without interfering with the existing chart or the deployment configuration of each service owner. They can also reuse the same Rollout subchart across multiple services, reducing duplication of effort.
• Flexible and scalable: Subcharts allow you to manage a large number of services with different deployment configurations in a flexible and scalable way. You can easily add or remove subcharts as needed, without affecting the overall deployment structure.
• Onboarding can be easier with out-of-the-box analysis templates for common use cases, like testing memory or CPU usage.
• Offboarding is easier, too. You only need to detach the subchart from parent, without rollback parent chart and release new version.

To summarize, Argo Rollouts is a useful tool for managing Kubernetes deployments, but switching from a Deployment to Rollout can be difficult. There are two options for migration, and using subcharts is the best method. This approach offers a good balance between ownership, flexibility, and ease of onboarding. Also, the transition to Argo Rollouts is smooth and improves the deployment process, ensuring efficient management of multi-tenant services at scale.

Date Published: June, 1, 2023