Argo CD v1.1 Released!

The Argo Team is happy to announce the general availability of Argo CD v1.1, a declarative GitOps deployment tool for Kubernetes. This release introduces Sync Waves, a major enhancement to the syncing functionality, improved OpenShift support, many usability and performance improvements, and dozens of bug fixes.

Special thanks to the following contributors: Aditya Gupta, jannfis, Liviu Costea, narg95, and Simon Behar. Thanks a lot for your help!

Sync Waves

Argo CD already provides the ability to control the syncing process using Sync Hooks. The syncing process consists of three phases: pre-sync, sync and post-sync. Sync Hooks allows executing custom logic packaged as a Kubernetes Pod, Job or Argo Workflow during each phase. This feature is typically used to perform database schema migration, run post-deployment health checks, or send notification about a failed sync operation.

With the v1.1 release of Argo CD, each sync phase (pre-sync, sync and post-sync) may consist of one or more sync waves. This fine grained control enables phased rollouts consisting of multiple deployments where one deployment can only proceed after another deployment is fully ready.

More information is available in the Agro CD documentation:

Optimized Interaction With Git

Argo CD communicates with Git to access Kubernetes resource manifests that compose an Application.

Application. A group of Kubernetes resources as defined by a manifest. This is a Custom Resource Definition (CRD).

Argo CD has several levels of caching to minimize the number of interactions with Git:

• The git repo content is cached on theargocd-repo-server file system, so that Argo CD only needs to do a git fetch when a new commit is pushed to the repo.
• Generated application manifests are stored in a shared Redis cache, so that the Kubernetes config management tool is executed only once per commit.

However, even with the above caching mechanisms, Argo CD still needs to resolve the HEAD, branch name or tag to the current commit SHA for each and every application reconciliation, which results in thousands of Git queries per day.

In v1.1 the reconciliation logic was improved so that the commit SHA is resolved only in one of the following cases:

• Once per every application re-sync period (3 minutes by default)
• When the user explicitly requests application refresh ( e.g. using argocd app get <appName> — refresh` )
• When Argo CD is notified of a new commit via a WebHook

These optimizations significantly reduced the number of Git queries. At Intuit, we are seeing a reduction of ~4–5x in the number of Git queries.

Improved OpenShift Support

Most Kubernetes APIs provide the same capabilities and behave in the same way. However, like any mature project, Kubernetes has some edge cases. One example is the Kubernetes extensions API group. The extensions API group was deprecated in 2017. Resources, such as Deployment, ReplicaSet, etc, were moved into a new API group. However, the extensions API group is still available after two years. So, whenever you create a Deployment, you will get twins: one Deployment in the extensions group and the same (but slightly different )Deployment again in the apps group.

Originally we implemented special handling for only the extensions API group. But quickly learned that this is not the only example. OpenShift has similar APIs requiring special handling:

• Every OpenShift Project resource automatically creates Namespace with the same name and UID
• Every resource created under the authorization.openshift.io group causes the creation of a duplicate under the rbac.authorization.k8s.io group.

Instead of continually adding special cases to the reconciliation logic, we’ve implemented a generic mechanism which uses resource UIDs to deduplicate problematic resources. In Argo CD v1.1, all special OpenShift API groups are supported the same way as the extensions API group.

Enhancements And Bug Fixes

In addition to these major improvements, v1.1 contains several smaller enhancements and bug fixes.

Kustomize images in UI

The application details page now contains information about images of Kustomize-based applications. This allows quickly finding image versions used in an application, and, if necessary, overriding the version:

Image versions are also available on the Deployment History panel. This helps in quickly identifying the required information about the recent version and making rollback decisions.

User-Defined Application Metadata

User-defined Application metadata enables users to define a list of useful URLs for their specific application and expose those links on the UI
(e.g. reference to a CI pipeline or an application-specific management tool). These links should provide helpful shortcuts that make it easier to integrate Argo CD into existing systems by making it easier to find other components inside and outside Argo CD.

New Prometheus Metrics

Two new Prometheus metrics were added to Argo CD v1.1.

The argocd_app_k8s_request_total metric. Argo CD uses the Kubernetes watch API to get information about cluster resources. Thanks to this, the reconciliation takes milliseconds and saves Argo CD from performing additional get requests. However, in some cases, the resource cannot be effectively cached.

• The APIs of some resources don’t provide watch capability.
• Argo CD might have to do aget during reconciliation if the conversion of a cached version to the version of the resource stored in Git is impossible.

In both cases, reconciliation is slower. The argocd_app_k8s_request_total metric helps Argo CD operators identify which applications cause slowness and help in resolving the problem.

The argocd_git_request_total metric allows tracking how many Git queries are executed by Argo CD. The metric has thetype label, which takes one of two possible values: ls-remote, checkout.

CLI Enhancements

A new --async CLI option for thesync command returns as soon as the sync request was received by Argo CD:

argocd app sync APPNAME --async

A convenience command to logout by deleting the local token in ~/.argocd/config:

argocd logout

Ability to rotate the bearer token used to manage external clusters:

argocd cluster rotate-auth https://192.168.64.66:8443

This command performs token rotation, using the following logic:

• Get current bearer token to cluster identify secret & namespace associated with the token (this information can be extracted from token’s JWT claims information).
• Transfer metadata (e.g. service account object reference) to a new empty secret.
• Wait for Kubernetes to populate new empty secret with a new token.
• Update Argo CD settings with new token and delete old secret.

Deprecation Notice

Kustomize v1.0 is deprecated and will no longer be supported in the Argo CD v1.2 release.

Thanks To The Community!

As usual, many thanks to the vibrant Argo community! Argo CD 1.1 has received a lot of help from the community including whole new features, bug fixes, documentation improvements, and testing of release candidates. We are also very thankful for the additional use cases and applications the community has driven for Argo CD!