Ultimate Flexibility for Argo CD Architecture

Argo CD is a flexible GitOps controller that solves various use cases. It might be used as a platform operator tool that performs cluster bootstrapping, as well as a GitOps-as-a-Service for hundreds of application developer teams. Depending on your requirements, you might choose different ways to deploy Argo CD components to achieve better scalability and save resources.

Centralized Argo CD

The most common way to deploy Argo CD is to use a single instance of Argo CD that manages all the clusters and applications. Argo CD was designed with this installation type in mind and provided the best user experience. Application developers get a single management tool to manage the applications they are responsible for, and the platform team gets a single pane of glass to see the whole infrastructure state. The main drawback is this approach introduces some management burden and security implications since now Argo CD needs to have access to all managed clusters as well as scalability challenges.

Argo CD Per Cluster

Another way to deploy Argo CD is to deploy it per cluster. This approach is more scalable and allows to reduce the management burden. However, it introduces some challenges for application developers as of now they must jump between different Argo CD instances to manage their applications. Also, the platform team loses the single dashboard where they can see the entire infrastructure state and must take care of multiple Argo CD instances instead.

Argo CD Per Business Unit

Argo CD per business unit is a good compromise that mitigates scalability challenges and limits the blast radius in case of an outage. The user experience is still good because, typically, engineers of one business unit work with the same set of clusters and rarely need to jump between different Argo CD instances. Platform team loses the single pane of glass, but still can get the state of a particular business unit infrastructure.

Which Architecture Is The Best

So is there an architecture that works for everyone? It is hard to say since, so far, we've looked only at scalability and security considerations. In real life, there are a lot more factors that might affect architecture decisions:

• Git Access. The most common concern we've learned is related to Git access. The 100% pull model when the Argo CD application controller and repo server reside inside the managed cluster is very attractive. The caveat is this approach assumes access to Git from every infrastructure node. Given that the Git server typically holds valuable code and this is a security concern. The perfect solution would be to host the repo server component in one dedicated cluster and use it as a proxy for Git access.

• Image Updater. Image updater is a component that watches the image container registry and updates the deployment manifests in Git when a new image is available. It represents a similar example to the Git access problem, except the image updater might need to be deployed to a different location than the repo server with elevated privileges.

• Application Set. ApplicationSet is an Argo CD component that automates Argo CD applications managed based on data available from various sources. Same as the image updater and repo server it might need to be deployed to the special cluster with elevated privileges.

Akuity's Answer

After working with many customers, we've learned that there is no one size fits all solution. Each organization has its own requirements and constraints. That's why we've taken a different approach and allowed our customers to choose the architecture that works for them. Akuity Platform provides hosted Argo CD and lets users choose where each component should be hosted, and takes care of connectivity between them. This approach allows us to achieve the best scalability and security while keeping the user experience at the same level.

Changing the dedicated cluster for a particular component is as easy as clicking a button or changing a single line in the configuration file if you prefer a declarative management style.

Use the following steps to change the location of the desired component:

• Navigate to Argo CD → your instance → Settings.
• Choose the desired component settings section.
• Select the desired Kubernetes cluster using Select Cluster control.
• Click the Save button.

To learn more, go to the Argo CD flexible architecture documentation section.

Conclusion

At Akuity, we've recognized that it's impossible to predict all the requirements and constraints of Argo CD users. That's why we've built a platform that allows them to choose the architecture that works for their specific use cases. This approach allows users to provision Argo CD instances and manage every cluster inside their entire organization utilizing the pull model without sacrificing security and without introducing scalability challenges and the management overhead.

Do you have a use case that the Akuity Platform does not cover? We are genuinely interested in learning more about it. Please reach out! We will be happy to help you solve your problem.