Argo CD v0.11 Released

Jesse Suen
Argo Project
Published in
4 min readJan 11, 2019

--

The Argo team is proud to announce the general availability of Argo CD v0.11, a declarative GitOps deployment tool for Kubernetes. This is our biggest release ever and introduces a completely redesigned controller architecture!

If you are new to Argo CD, visit our GitHub page for a quick primer, take a look at this short demo for the Kubernetes community, or this KubeCon presentation on how Intuit uses Argo CD. Here are some of the highlights of what we’ve been working on!

Performance & Scalability

The application controller has a completely redesigned architecture for improved performance and scalability. Argo CD can now scale to very large Kubernetes clusters containing hundreds or even thousands of applications. What used to take 30 seconds to refresh and reconcile a single app can now be done instantly. Not only that, refreshing and reconciling hundreds of applications only takes a few seconds!

Object relationship visualization for CRDs

Since its first release, Argo CD has always been able to show “ownership” between Kubernetes objects. However, this was limited to just the built-in types. With v0.11, Argo CD can now visualize parent/child relationships between any kubernetes objects, including custom resources. Below, looking at an instance of a Prometheus CRD, you can see its associated ConfigMap, StatefulSet, Service, and Secret objects.

Multi-namespace applications

Argo CD applications have traditionally been tied to a single namespace. A common request from the community is to support a single application that has resources in multiple namespaces.

Argo CD now honors any explicit namespace defined in the metadata.namespace field of the manifest. Manifests with the namespace field omitted will continue to be deployed to the application’s “preferred” namespace, as specified in spec.destination.namespace. This new behavior enables support for complex applications, such as the prometheus-operator, which deploys resources into bothkube-system as well as the application’s namespace.

Large application support

Previously, Argo CD had a limit on the total number of resources that comprised the app. This was because we were storing the entire live/git manifests inside the application status which would cause some applications to reach the 1MB etcd object size limit. We now only store essential metadata information, such as a resource’s sync and health status.

This change enables Argo CD to support much larger applications containing hundreds of resources objects (e.g. Istio), while also reducing the object payload size, improving responsiveness when listing applications in the UI.

Resource lifecycle hook improvements

Many improvements were made to Argo CD’s Resource Lifecycle Hooks. Hooks are now visible from the UI, where you can view its logs, kubernetes events, or delete it just like any other application resource. Additionally, bare Pods (with a restart policy of Never) can be used as a resource hook as an alternative to Jobs or Argo Workflows.

Kubernetes recommended application labels

The tracking label which Argo CD injects into application resources for pruning, has been changed to use app.kubernetes.io/instance label as recommended in Kubernetes recommended labels. This enables applications managed by Argo CD to interoperate with other tooling following the standard such as the Kubernetes dashboard.

OIDC (OpenID Connect) Enhancements

External Provider Support

Argo CD has always bundled the Dex IDP OIDC provider as part of its default installation. The aim was to provide an easy and seamless out-of-the-box experience when integrating with either traditional identity providers (LDAP, SAML), or with non-OIDC providers (GitHub, BitBucket, GitLab) using Dex’s full range of connectors.

For users who don’t need Dex and are already using their own OIDC provider (e.g. Okta, OneLogin, Auth0, Microsoft, etc…), Argo CD now supports auth delegation to an existing, external OIDC providers. See the OIDC documentation on how this can be configured.

Group Claims Bindings to Argo CD Project Roles

Managing user access to Argo CD applications has never been easier! New in this release, is the ability to bind OIDC group claims to Argo CD project roles. Previously, this could only be accomplished by editing the policy.csv in the centralized argocd-rbac-cm ConfigMap. Now, this can be easily managed using the UI.

Declarative Argo CD Setup

It was always ironic that as a declarative GitOps tool, Argo CD’s own configuration was imperative, and difficult to configure without the help of the UI/CLI. In v0.11, Argo CD settings can now be configured declaratively via its ConfigMap, or imperatively via the Argo CD CLI/UI as before. For details, see the declarative setup documentation.

Helm repository support

Custom helm repositories can be configured at the Argo CD system level. This enables support for helm charts which have a dependency to external, non-standard helm repositories, such as private helm repositories, or non-standard public repositories such as the ones listed in Helm Hub.

Thank you for your support!

We are very close to a v1.0 version of Argo CD, but we aren’t quite done yet! A huge thanks to our awesome community who has given us great feedback for improvements, tested pre-releases in their own environments, and contributed back features and bug fixes!

--

--

Co-founder and CTO at Akuity | Argo Project Leader with 6-year tenure | ex-Intuit | ex-Applatix | Running the Enterprise Company for Argo — https://akuity.io