How to Migrate from Flux to Argo CD | Live Demo

Summary

In this live demonstration, two developer advocates explore the process of deploying a Helm chart with Flux and transitioning it to Argo CD without causing downtime. They walk through Flux installation, chart deployment, and managing GitOps with Flux and Argo CD. The session highlights the smooth integration of both tools within a Kubernetes cluster, showcasing how Argo CD can take over Flux-managed resources non-destructively. The demo concludes with insights into the challenges of GitOps tool migration and future exploration of advanced Argo CD features like Progressive Rollouts and multi-source applications.

Takeaways

• 😀 Flux and Argo CD are both CNCF graduated projects, and this session explores their interoperability in a GitOps workflow.
• 😀 The session demonstrates deploying a Helm chart using Flux, followed by transitioning the deployment to Argo CD with no downtime.
• 😀 Flux is installed using the Flux CLI and a GitHub token, with a local Kubernetes cluster bootstrapped to deploy resources.
• 😀 The Helm chart deployment is managed by Flux via Custom Resources (CRs), which define the configuration and chart source for Kubernetes resources.
• 😀 Transitioning to Argo CD involves creating an application in Argo CD to manage the same resources that Flux is deploying, ensuring minimal disruption.
• 😀 The presenters explore how Flux and Argo CD manage resources, noting differences in configuration and deployment behavior.
• 😀 Flux is uninstalled in a dry-run mode to simulate the impact of removing Flux and ensure Argo CD can take over without disrupting the deployed resources.
• 😀 The migration process involves synchronizing Argo CD with the existing Flux-managed resources, ensuring that the transition is smooth and non-destructive.
• 😀 The session highlights the complexity of migrating between GitOps tools, especially when dealing with additional components like Sops or more complex environments.
• 😀 Future content could delve into advanced features of Argo CD, such as progressive rollouts and handling multiple sources for applications.
• 😀 The key takeaway is that while migrating GitOps tools is feasible, it requires careful planning, especially when transitioning complex configurations or dependencies.

Q & A

What is the goal of the demonstration in this video?

The goal is to deploy a Helm chart into Flux and then transition that deployment to be managed by Argo CD, exploring the interoperability between these two GitOps tools.

Why is the presenter working with Flux and Argo CD in this demo?

Both Flux and Argo CD have recently graduated from CNCF, indicating that they are now widely adopted tools. The presenter is exploring how well these tools work together in a real-world scenario.

What is the significance of Flux and Argo CD being CNCF graduated projects?

CNCF graduation means that the projects have gained widespread adoption, passed rigorous tests for stability, and are now officially considered production-ready and trusted by the community.

What tools and services are being used in this demo?

The demo uses Flux CLI, Helm, Argo CD, GitHub repositories, and a local Kubernetes cluster managed by Kind.

What did the presenter mean by 'cheating' when getting started with Flux?

The presenter used a pre-existing 'Getting Started with Flux' guide created by Christian Herman to make it easier to get Flux running in their environment quickly.

What challenges does the presenter expect when transitioning from Flux to Argo CD?

The presenter expects challenges related to potential conflicts between Flux and Argo CD, as well as figuring out how to smoothly transition without downtime or undesired changes in the deployed resources.

How does Flux manage Helm releases?

Flux uses custom resources (CRs) like HelmRelease to manage Helm charts, specifying where to find the charts and how to deploy them. The HelmRelease CR references other CRs like GitRepository to pull the chart details from a Git repository.

How does Argo CD differ from Flux in managing applications?

Argo CD uses the concept of an 'Application' to manage resources. It pulls application specifications from a Git repository and applies them to a Kubernetes cluster. Flux, on the other hand, uses multiple CRs like GitRepository and HelmRelease to describe and manage these resources.

What are the key steps involved in transitioning from Flux to Argo CD in this demo?

The key steps are setting up Flux to deploy the Helm chart, then configuring Argo CD to manage the same Helm chart without causing conflicts, ensuring that resources already deployed by Flux remain unchanged during the transition.

How did the presenter ensure a smooth transition from Flux to Argo CD with no downtime?

By manually syncing Argo CD to ensure it only adds tracking IDs to existing resources, and using Flux's dry-run uninstall feature to check what would be deleted, the presenter ensured that no critical resources would be removed or modified destructively during the transition.

What does the presenter mean by 'non-destructive' operations when transitioning to Argo CD?

Non-destructive operations refer to actions that do not remove or alter existing resources. In this case, syncing Argo CD to add tracking annotations instead of making changes to the actual deployed resources ensures that the transition is smooth and without downtime.