Declarative Continuous Delivery for Kubernetes: A Closer Look at Argo CD

Argo CD is a Continuous Deployment solution that provides Kubernetes first support. It follows Git-based workflows to automate the deployment of services and applications within Kubernetes. In this post, we will take a close look at the capabilities of this declarative continuous delivery system for Kubernetes and share our thoughts on Argo CD.

The origins of Argo CD

Argo CD was announced in 2018 as an open-source project by the Argo Community and Intuit. It was introduced as a continuous deployment solution for the Kubernetes community when solutions like Spinnaker failed to support Kubernetes-native workflows. Argo CD works based on the GitOps model, where git repositories are the single source of truth for the state of your Kubernetes infrastructure.

This is known as a pull model, where the solutions monitor and update your Kubernetes resources based on configurations defined in Git. In a push model, a user triggers an event from an external system or service. Argo CD can support both pull- and push-based models to sync your target environments with your desired application state. A common use case is to use a CI pipeline to trigger your CD pipeline.  

Argo CD was meant to be the first step in “achieving continuous operations” based on monitoring, analytics, and automated remediation of operational problems based on declarative specifications and automated learning / automatic categorization of system behavior.” Other Argo projects that help support this mission are Argo Workflows https://github.com/argoproj/argo, now an incubating project under the Cloud Native Computing Foundation (CNCF) for orchestrating parallel jobs on Kubernetes.

What does Argo CD do?

Argo CD allows users to control and orchestrate their defined Kubernetes manifests.

Kubernetes manifest files can be specified through:

• kustomize applications
• helm charts
• ksonnet applications
• jsonnet files
• plain directory of YAML/JSON manifests
• or any other management tool and format that allows for Kubernetes configuration.

Alongside these solutions, Argo CD automates the delivery of these definitions into their target environments. It does this very well, and the overall use of Argo CD provides a quick method for teams and developers to deploy quickly.

While Argo CD has many features, some of them are more enterprise-ready than others.

Top Argo CD Features

As a continuous deployment solution, some of the best features of Argo CD include:

1. Automated deployment of applications to specified target environments. 

Agro CD allows users to leverage their tooling to apply any changes needed to a specified Kubernetes environment, such as a helm chart, or application deployment. This is great for organizations that manage multiple Kubernetes resources. The Argo CD resources are explained in this document: https://argoproj.github.io/argo-cd/operator-manual/declarative-setup/.

Argo CD also provides tracking strategies for these deployments: https://argoproj.github.io/argo-cd/user-guide/tracking_strategies/. This is an example screenshot when getting started in Argo CD. The auto-sync capability provides status and additional information about your deployment.

2. Health status analysis of application resources. 

Argo provides additional details about a deployment’s health status. Auto-sync to your git repository is also available, as shown below. 

Argo CD also has automated configuration drift detection and visualization. The drift detection is based on the same logic found in kubectl diff. A deployment is out of sync if there is a difference between the live Kubernetes manifest file and the source of truth manifest file found in git. I recommend this resource for reading more about the out-of-sync status and how it is used: https://argoproj.github.io/argo-cd/user-guide/sync-options/. It may be helpful if your environment or application architecture changes often.

3. A web user interface (UI) that provides a real-time view of application activity.

Most delivery platforms today either have a UI or are in the process of introducing one. Having visibility into the real-time status and activity of an application gives teams increased visibility and ensures everyone with a stake in a deployment is able to respond.   

Top Argo CD Challenges

Adopting a solution that fits your organization’s needs and use cases can help accelerate your time to market. However, evaluations are often not straightforward, and hindsight is often 20/20. Here are some challenges you may encounter with Argo CD.

1. Managing the solution itself.

Open source solutions offer quick ways of getting started. Engineers can download and install an instance of the solution, accelerating the learning curve on the necessary processes and technology concepts needed to deliver. But this model does not often scale for software delivery solutions as organizations, processes, and technology change over time. Some key challenges may include scaling and bootstrapping Argo CD. An Argo CD installation is required in every Kubernetes cluster. Updates and installations are also self-managed, and teams will need to dedicate capacity to support the solution.

2. Fool-proofing changes.

Part of how we scale software delivery is about how we manage access, permissions, and secrets. The last thing teams need is for unauthorized users to change or introduce a breaking change to a production environment. Argo CD users may face challenges in securing their environments. To date, there is no  built-in Argo CD support for encrypting secrets. For discussion, see #1364. RBAC and SSO are also not linked, so administrators of the solution will have to control access and define user groups without leveraging user data provided by the SSO provider.

3. Meeting the needs for Continuous Delivery.

For many organizations, we want to do more than allow changes to be available. Site Reliability Engineering, DevOps, and CI/CD all exist to support the continuous software lifecycle, and often our workloads can be spread across other platforms and technologies that don’t involve Kubernetes and containers. Argo CD does not support non-Kubernetes workload. And users may also challenge by automating the responsibilities and requirements needed after an application or service deployment. This includes verification and incident management. Rollbacks are manual in Argo CD, and there are capabilities of auditing changes made within Argo. Since Argo works on the GitOps model, changes are all committed to a git repository. This means your playbook for handling incidents may need to include additional enablement and integrations to automate many of the post-deployment activities.

The Verdict

Argo CD has its capabilities. While it offers a seamless experience for developers, it will need more features for supporting DevOps and Operations teams if it is to scale as a delivery solution. I’m optimistic that many of the changes will benefit end-users, especially as the Argo Community grows, given the guidance they receive from such a strong number of end-users, developers, and contributors.

If you are currently evaluating Argo CD, consider your biggest pain points around software delivery. If you have a large number of clusters, it may be difficult to install, manage, update, and configure an instance of Argo CD across all of those clusters. Likewise, if you have a large number of services, consider evaluating the solution on how well it scales horizontally. I recommend considering the average time to onboard services or engineers into the solution and if it’s possible to templatize workflows.