Argo CD Clusters and Repositories - Two Core Components

Illustration of a person scuba diving near underwater plants with a jellyfish-like creature in the foreground, reflecting an underwater scene with a sunbeam effect. Illustration of a person scuba diving near underwater plants with a jellyfish-like creature in the foreground, reflecting an underwater scene with a sunbeam effect.

Let’s talk about two resource types inside Argo CD: Clusters and Repositories. Both of those things are configured globally in your Argo CD server. I think you can easily guess what both of those resource types are, but let’s just go through configuring them.

Repositories

There are two types of Repositories in Argo CD - Git repositories and Helm repositories. As Argo CD is a GitOps tool, let’s focus on Git repositories for now. I am going to add a helm-lightning-course repository - it’s a public repo that contains a PGAdmin Helm Chart, the one that is written during our free Helm course.

I will select HTTPS connection method and specify the Repository URL. That’s actually everything I need! Of course, for private repositories I would also need to specify some kind of authentication - either with SSH keys, or with username and password.

There is also something called “Credentials Template” - you can basically specify a prefix that is identical for all your repositories - for example, github.com/mkdev-me, and specify which credentials should be used for all repository that start with this prefix.

This is handy if you don’t want to specify credentials for each repository individually, and you simply configure some kind of technical user that has access to all repositories of your organization, or of your team.

I am not going to do that, and will simply add a PGAdmin repository - ArgoCD confirms, that connection is succesful, meaning it is able to pull the code from this repository.

Clusters

The next thing we need to configure are clusters. The cluster where Argo CD is running is already here - it’s called “in-cluster”.

Screenshot of Argo CD web interface with cluster settings page showing server, credentials type, name, and namespaces information along with an unknown connection state.

We already can deploy applications to the same cluster where Argo CD is running. But one of the core benefits of having a tool like Argo CD is the ability to deploy applications to many different clusters. Luckily, I do have another Kubernetes cluster!

To add it to Argo CD, I am going to use Argo CD’s command line interface - this CLI is a great little tool to do some ad-hoc operations on Argo CD server. If you have only a handful of Kubernetes clusters, then adding them with a CLI is totally okay. Just keep in mind, that once you treat your clusters like cattle, then you should automate adding them to Argo CD.

I am going to install the CLI with brew install argocd.

Next, I need to log in to the server. I have to use grpc-web option because I am using AWS ALB, and plaintext and skip-test-tls options because I did not configure TLS for my Argo CD - don’t do that in production.

argocd login SERVER:80 --grpc-web --skip-test-tls --plaintext

Before I will run a command to add a new cluster, I first need to add a Kubeconfig context for the new cluster:

aws eks update-kubeconfig --name mkdev-labs-euc1-cargo101prod

Now I can add this cluster to Argo CD:

argocd cluster add arn:aws:eks:eu-central-1:170837768887:cluster/mkdev-labs-euc1-cargo101prod --name mkdev-labs-euc1-cargo101prod

The first argument is the name of the Kubeconfig context that allows the CLI to connect to the API of the target cluster. Argo CLI needs this in order to create a new service account and cluster role - Argo CD server will use this service account to connect to this cluster. Note that this will give Argo CD a full cluster admin access on a target cluster - you will probably want to narrow this down if you have a big multi tenant cluster.

A computer terminal screen showing command-line text of a user setting up Argo CD on a Kubernetes cluster, interacting with AWS services, and configuring access and service accounts.

If we go back to the Argo CD Web UI, we will see this new cluster in place. It tells us that the cluster status is unknown - that’s because we did not deploy any applications yet.

Screenshot of Argo CD platform with cluster settings displayed, showing general server information, token authentication type, and an unknown connection state.

Remember how I told you, that Argo CD stores everything inside Kubernetes’s API? Another example of it is how Argo CD stores this cluster information. If we run kubectl get secrets -n argo, we will notice a Secret dedicated to storing the information about the new target cluster.

Screen capture of a computer terminal with command-line interface showing the result of a Kubernetes secrets retrieval command.

If we examing this secret, we’ll see a label argocd.argoproj.io/secret-type: cluster - that’s how Argo CD is able to understand that information inside this secret is about the target Kubernetes cluster.

An image displaying a text snippet of a digital document or command-line output containing JSON data with fields like 'server', 'kind', 'metadata', 'annotations', 'name', and encrypted data strings.

It’s time for us to deploy something with Argo CD. In the next lesson we are going to finally learn about Projects and Applications.


Here' the same article in video form for your convenience: