Bye to ClickOps: What Argo CD Is and Why Native Kubernetes CD Matters

Of the many building blocks that go into deploying successfully to a Kubernetes cluster, it’s hard to get more essential than Argo CD. When you use it as part of your deployment workflow, it becomes the “puppetmaster” for getting all your applications and clusters into your desired state.

At Kubefirst, we love Argo CD because it eliminates any reliance the “ClickOps” paradigm, of running `kubectl apply` or `helm install` manually, which has been the root cause of indecipherable inventories of Kubernetes resources and the dreaded secret-scattering.

But if you’re not already familiar with what it is, its value propositions, and how you deploy to Kubernetes when you use it alongside proper GitOps processes, now is the time to dig in.

What is Argo CD?

Let’s start with the simplest possible definition: Argo CD is an open source GitOps continuous delivery tool for Kubernetes.

That short statement deserves to be broken down.

• Open source: Argo CD is currently developed on GitHub by the Argo Project, but was started at Intuit before being released under an open source license. Today, it's a Graduated project from the Cloud Native Computing Foundation.
  
• GitOps: A development and deployment paradigm where your Git provider, like GitHub, stores the desired state for your Kubernetes cluster and your applications in the `main` branch of your repository. With GitOps, your entire infrastructure is declarative and version-controlled.
  
  At Kubefirst, we have a lot of strong thoughts about what GitOps is and why you should be using it.
  
• Continuous delivery: A practice where code changes are automatically released to production, but unlike the traditional CI/CD pipeline you’d get with something like Jenkins, Argo CD operates like a Kubernetes engine, entirely separate from any CI (Continuous Integration) processes. You’re no longer responsible for the CD part—Argo CD does all its calculations and syncing on its own—which lets you focus on properly establishing your desired state.
• … for Kubernetes: Argo CD isn’t an external SaaS app that you plug into your Kubernetes cluster with secrets—it’s installed directly into each Kubernetes cluster in your infrastructure and given read-only access to your GitOps repository.

Argo CD listens for a webhook from your Git provider, which lets it know the state of your GitOps repository has changed due to a merge in your `main` branch. Argo CD clones the repository, calculates the desired state, and creates the necessary resources using native Custom Resource Definitions (CRDs). The best part is that all this happens within your Kubernetes cluster, dramatically simplifying how you manage and observe your deployments after the fact.

There is a way (hint, the kubefirst project) to deploy a management cluster with Argo CD easily, which allows you to view all environments’ applications from a single instance—more on our open source cloud provisioning tool a little later.

Argo CD has become one of the most popular cloud native projects because of its effectiveness and position at the heart of the Kubernetes development and deployment lifecycles. Today, the Argo community consists of more than 7,000 developers from almost 2,000 contributing companies. You can learn more about the continued velocity and diversity of the Argo community in their CNCF Project Journey Report.

Deploying Kubernetes applications with Argo CD and GitOps

It’s one thing to understand what a cloud native tool or project is on a technical level, another thing entirely to grasp how it will affect your team’s day-to-day configuration and deployment lifecycles.

While Argo CD might be a complex project under the hood, once it’s running in your cluster and connected to your GitOps repository, your workflows should get simpler. For example:

1. You push changes to an application to your Git provider.
2. These changes trigger your CI pipeline to build containers, publish them, set a new desired state, and then run any integrated tests.
3. You then open a pull request/merge request.
4. Your peers review your work and suggest changes, and once your changes are approved, they’re merged into the `main` branch.
5. Your change to `main` triggers a webhook, which notifies Argo CD that the desired state has changed.
6. Argo CD pulls the repository and calculates the resources necessary to achieve the desired state, then identifies where the current and desired states diverge.
7. Native Kubernetes controllers sync/reconcile the changes until it achieves the configuration as specified in the `main` branch.
8. Argo CD then reports the sync result back to your Git provider or any other destination you might’ve set up.

You don’t have to switch IDEs, install a half-dozen plugins, or change up how you’re doing code collaboration on GitHub or GitLab. All that changes is that you only have to worry about what goes into your GitOps repo.

Why should you want native Kubernetes CD?

Aside from a streamlined workflow, you might still be wondering the value of having a native Kubernetes CD. Why not just stick with the ClickOps fundamentals of running `kubectl apply` and `helm install`? People have been using these commands for years, and the Kubernetes community has produced countless educational resources to guide developers of all experience levels through the fundamentals.

First and foremost, when you use ClickOps, you’re getting almost none of the benefits of GitOps and all the messiness of deployment scripts and run lists of the past. It’s not that different from letting anyone click a green button to deploy an application or entire cluster without oversight from the DevOps or SRE teams. It’s not much better than `ssh`-ing into a Virtual Machine (VM) and copy-pasting a few dozen commands from a DigitalOcean tutorial directly into a Bash prompt.

When you opt for native Kubernetes CD and GitOps, all your application definitions, configurations, and environments are declarative and version controlled. When you want to create a new environment in your cluster for development or staging, for example, you can duplicate the existing folder structure for your configurations and apply new values—Argo CD takes care of the rest.

Because Argo CD uses native Kubernetes CRDs, all the calculating of state, divergence, drift, and syncs happens within your cluster for added scalability and cost savings across the board. Your security posture is improved as well, because you don’t need to provide individual developer access to your infrastructure, only Argo CD.

All in all, your entire application lifecycle is automated, auditable, and easy for anyone to understand. That spins out into other massive benefits:

• With all your applications and configurations declared in a single GitOps repo, everyone can agree on a single source of truth for every version of every app.
• That repo’s Git history becomes an audit log of every system change, including who made and approved it.
• Because system-level changes happen in one place—the `main` branch of your GitOps repo—you simplify any security and approval controls you want to implement.
• Rollbacks become as simple as reverting a problematic Git commit.
• In the unfortunate event of disaster recovery, your declarative state in Git can be read by another instance of Argo CD, in a separate cluster, to stand up your infrastructure again as quickly as possible.

The shortest path to Argo CD and GitOps

If you’d like to roll Argo CD into your Kubernetes workflows today, you can always read the docs—you’ll need a running cluster, `kubectl`, a kubeconfig file, and CoreDNS. You’ll use `kubectl` to create a new namespace and deploy Argo CD’s manifests, then create a load balancer, ingress, or forwarded port to help you access the API server. Once you’ve logged in via the CLI tooling, you can integrate with your Git provider and start syncing/deploying.

If that sounds like a lot of work, you might consider giving kubefirst a shot. Our open source registry of agnostic Kubernetes projects already has all the glue and integrations you need to get started with native continuous deployment and GitOps right away. We even have a welcoming Slack community of developers and engineers who’ll be happy to share their experiences and best practices on application delivery and infrastructure management.

In just a few minutes, you’ll be able to upgrade your team out of the ClickOps doldrums with a single GitOps repository, and a `registry` folder, that automatically adds new applications/environments and keeps everything perfectly in sync. No more ClickOps, just seamless and continuous delivery from the best source of truth there is: your Git repository.