Introducing Argo CD v1.8 Release Candidate

The Argo CD v1.8 release is almost here. The team just published the first release candidate and is excited to share what’s new in this release!

Scalability And Performance Improvements

As Argo CD adoption continues to grow, we have to keep pushing Argo CD scalability limits again and again. This is probably a never-ending quest, but the v1.8 release is a huge step forward. We have implemented improvements that enable a single Argo CD instance to comfortably manage thousands of applications across hundreds of clusters. This enables advanced use cases such as “cluster addons”, large mono-repositories, and opens the door for the ApplicationSet project that will solve an important multi-cluster application management problem. Dive deep with us to learn the exciting details!

Mono-Repository Sync Improvements

As part of each state reconciliation cycle, Argo CD fetches configuration files from the Git repository and produces the final manifests. This job is done using a component called argocd-repo-server. The argocd-repo-server works perfectly fine if the application manifests are evenly distributed across multiple Git repositories and each repository contains manifests for only a few Argo CD applications. However, the performance degrades if all the application manifests are stored in a mono-repository — often a repository that represents the desired state of the entire cluster and including hundreds of applications.

We’ve implemented as set of optimizations as part of v1.8 release and mono-repository is no longer an issue for Argo CD. The internal testing so far shows great results! Manifest generation of 50 applications takes one-tenth of the time after upgrading to v1.8 and we scaled down instances of argocd-repo-server from 6 to 2 replicas. Read more about it in the Argo CD documentation!

Annotation Based Path Detection

The v1.8 Argo CD allows you to explicitly specify which directories in the source repository are important for the manifest generation using the argocd.argoproj.io/manifest-generate-paths annotation. The following YAML contains an application that depends only on one folder in the source repository specified in spec.source.path field:

The Git webhook handler and annotation allows Argo CD to skip unnecessary application reconciliation if Git webhook detects that no application related files have changed. Additionally, webhook reuses manifests cached from previous commit SHAs if no changes are detected. This not only prevents unnecessary application reconciliation but also skips manifest generation altogether in many cases. Read more about this in the Argo CD documentation!

Horizontal Controller Scaling

Last but not least, we’ve improved argocd-application-controller scalability. Until the v1.8 release, the argocd-application-controller is the only component that could not be scaled horizontally. Among other things, the controller is responsible for maintaining the target Kubernetes cluster cache and application reconciliations which requires memory and CPU. This becomes a bottleneck if your Argo CD instance manages more than a hundred Kubernetes clusters. The v1.8 Argo CD release introduces cluster shards and allows running multiple instances of argocd-application-controller.

Each controller replica is responsible for a subset of connected Kubernetes clusters and related Argo CD applications. This allows connecting as many clusters as needed to one Argo CD instance and you can improve reconciliation performance just by increasing the number of controller instances.

New Core Functionality Features

Besides performance improvements, Argo CD got a lot of usability enhancements and new features. Let’s start with the core functionality improvements.

Namespace and CRD creation (#4354)

Namespaces and CRDs are special resources that generally need to be created before other resources, as they can block creation of other resources in that namespace or resources of that CRD kind. This enhancement simplifies bundling namespace and related resources. Argo CD automatically detects resources that are referencing a namespace and creates the namespace first. It also identifies custom resource definitions (CRDs) that need to be created before creating instances of the same custom resource.

Unknown fields of built-in K8S types (#1787)

When syncing resources with validation turned off, Argo CD silently dropped unknown or invalid fields from the source manifests. The result was that resources were not considered out-of-sync when such unknown fields were added, deleted or modified. With v1.8, this behavior has changed and Argo CD now correctly considers resources with modified unknown fields to be out-of-sync.

Endpoints Diffing (#1816)

An Endpoint is a built-in Kubernetes resource that (amongst other information) includes a list of IP addresses. The Kubernetes Endpoint controller re-formats Endpoint spec and sorts these IP addresses alphabetically. This behavior confuses Argo CD (as well as kubectl client-side diffing) and causes false-positive deviation detections. Starting with v1.8, Argo CD will now gracefully handle the order of IP addresses and compare them properly.

Better compatibility with Helm Hooks (#1816)

Argo CD provides first-class Helm support for a while now, including a feature to map Helm hooks to Argo CD hooks. This release removes a slight discrepancy in sync hooks deletion logic between Argo CD and Helm that was causing issues in some OTS Helm charts.

App-of-Apps Health Assessment (#3781)

The App-of-Apps is a popular pattern that allows Argo CD to declaratively manage itself using GitOps methodology. We’ve learned that built-in health assessment of the Argo CD Application CRD often causes confusion and only few users rely on it. As a result, built-in health assessment has been removed and still can be configured manually if required.

Global Projects

Argo CD Project is a Kubernetes custom resource that represents the logical Applications group. Projects are used to implement multiple Argo CD features that are required in a multi-tenant environment. Argo CD operators are using projects to separate teams from each other and to enforce various organization rules. For example, you can specify a list of clusters available for deployment within the project or stop users from pushing changes on Friday night using the Sync Windows feature.

This release makes it easy to manage an Argo CD that has hundreds of Projects. Instead of duplicating the same organization-wide rules in all projects you can put such rules into one project and make this project “global” for all other projects. Rules defined in the global project are inherited by all other projects and therefore don’t have to be duplicated. The sample below demonstrates how you can create a global project and specify which project should inherit global project rules using Kubernetes labels:

User Interface Improvements

The Argo CD user interface is an important part of the project and we keep working hard on improving the user experience. Here is an incomplete list of implemented improvements.

Improved Applications Filters (#4622)

It is much easier to find and clear filters applied on the applications list page.

Git tags and branches autocompletion (#4713)

You no longer need to remember branch and tags names in your Git repository during application creation:

Project Details Page (#4400)

Project details page now is consistent with Application details page:

The list of user interface improvements is too long for one blog post. Install Argo CD v1.8-rc1 to see changes described above as well as the new version information panel (#4376), progress Indicators (#4411), external links annotations (#4380), and many more.

Config Management Tools Enhancements

OCI Based Repositories (#4018)

Many popular Helm registries started providing Helm charts using the new, standardized OCI protocol. Helm v3 supports OCI registries as an experimental feature for a while now, and we are happy to announce that Argo CD is now able to manage Helm charts provided in OCI registries as well. You can simply connect a new Helm repository for creating Applications from Helm charts, and Argo CD will automatically detect whether the repository is a classic Helm repository or an OCI repository and is able to fetch Charts from either of the two.

Configurable Helm Versions (#4111)

Argo CD has first-class support for Helm, both v2 and v3. Up to Argo CD v1.8, the decision for which Helm version to use for rendering a given chart was made by evaluating the apiVersion field in the chart’s definition. Since charts created by a different Helm version could lead to compatibility issues, you can now explicitly override the desired Helm version to use in the Application’s spec.

Bug fixes and under the hood changes

In addition to new features and enhancements, we’ve fixed more than 50 bugs and upgraded third-party components and libraries that Argo CD relies on.

Where Can I Get the New Release?

For more details and installation instructions, check the release notes, and upgrade instructions.

Thanks To The Awesome Community

Argo CD received 300+ PRs from more than 100 contributors since the v1.7 release on August 15th, 2020. That is ~3 pull requests and one new contributor every day including weekends which is just incredible. We cannot say enough to express how grateful we are to everyone who contributed.