Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. It follows the GitOps pattern of using git repositories as the source of truth for defining the desired application state. With ArgoCD, application deployments can be automated and updates to application can be made at the simple git commit events without the need of any complicated Continuous Integration and/or Deployment Pipelines.

This is our fourth post in the series of blog post on deploying and managing application with Kubernetes and Argo CD. You can find the series index here.

Deploying Helm Charts with Argo CD

A lot of applications have defined their manifests in the form of Helm Charts. Argo CD will assume that the Helm chart is v3 (even if the apiVersion field in the chart is Helm v2), unless v2 is explicitly specified within the Argo CD Application (see below).

If needed, it is possible to specifically set the Helm version to template with setting the helm-version flag on the cli (either v2 or v3):

argocd app set helm-guestbook --helm-version v3

where helm-guestbook is the name of the application.

Add Helm Repositories to Argo CD

You may have helm charts hosted as separate repos or as part of other git repos. Lets see how we can add helm chart repositories to the Argo CD. Lets add Bitnami Charts repo to our use case.

For this, we can go to Settings -> Repositories -> Connect Repo using HTTPS and submit below details:

Type – Select Helm since we are adding helm charts repo. If your application specific are part of github repo, select github.

Name – Provide a unique name for the repository inside argocd workspace. We’ll select it as Bitnami in our case.

Repository URL – Provide the URL for fetching manifests. If the repository is public, you do not need to provide any additional authentication details. So we’ll leave that as empty for our case.

Once done, click connect to save the configuration. If Argo CD is able to fetch the manifests, it should mark the connection status as successful:

Create New Application Inside Argo CD

We now need to create an application so that we can operate on it using Argo CD. Go to Applications and click the + NEW APP button and fill the upcoming form. After that, we need to submit details as below:

Application Name – This is the application name inside Argo CD. You can use Argo CD to manage multiple application at once. We’ll set it to helm-demo in our case.

Project – This is the project name inside Argo CD. Project can be used to segregate and group applications together. Since this is a new setup for Argo CD, a default project is created for us and we’ll select the same. If you have multiple projects together, you’ll see an auto-populated list and you can choose the same.

Sync Policy – You can choose to auto synchronize the state of application in the Kubernetes with the GitHub repository or you can set it to manual. There are many choices, and we’ll probably discuss it in more details later. For now, leave it as manual.

We now need to provide the Helm repository details containing the application manifests, in the same form. Submit the details as below:

Repository URL – Provide the url for the Helm repository containing the application manifests. It will list any pre-populated repositories, and we can select the repo from the list. Alternatively, provide the new repository url.

Select Repository type as HELM.

Chart – Again, this will be pre-populated with the list of charts available in the repository. You can select anyone you want to deploy. For our case, we’ll select simple such as apache.

Revision – Select the chart revision you want to deploy.

Once we have provided source details where we described the desired state, we now need to provide the destination Kubernetes cluster details as below:

Cluster URL – Argo CD can be used to connect and deploy application to multiple Kubernetes clusters. Inside the UI, you’ll not get the option to add and connect a different Kubernetes cluster. This feature is restricted to Argo CD CLI. For our case, we’ll use the default in-cluster (where Argo CD itself is deployed).

Namespace – This can be used to select namespace where manifests will be deployed. You can choose a custom namespace and provide the same. Also, you’ll need to create the namespace on the target Kubernetes cluster before you can deploy manifests to it. Alternatively, you can select the checkbox for ‘AUTO-CREATE NAMESPACE’ in the sync options. We’ll leave it as default in our case.

Note that the namespace specified inside Kubernetes manifests overrides this value.

After filling out the information above, click Create at the top of the UI to create the helm-demo application. After this, it will read out all the parameters, read the source Kubernetes manifests. After this, it will go to OutOfSync state since the application has yet to be deployed, and no Kubernetes resources have been created.

Modify Helm Chart Values and Parameters

Helm has the ability to use a different, or even multiple values.yaml files to derive its parameters from, which are present in the same path as helm chart. We can choose to override the helm values by editing the application inside Argo CD workspace:

We’ll override ghost service port to 31001 and service type as NodePort in the helm parameters.

Synchronize the Application Manifests / Deploy the Application

As we mentioned above, the application status is initially in OutOfSync state since the application has yet to be deployed, and no Kubernetes resources have been created. To sync (deploy) the application, we can choose the tile and then select SYNC. This will present us with a choice about what we want to synchronize:

We’ll select default options and synchronize all manifests. Once its deployed, we can see the resources deployed in the UI:

Alternatively, we can also use the Kubectl:

mohitgoyal@desktop:/mnt/d/mohit/src/kind$ kubectl get all -n default
NAME                                    READY   STATUS    RESTARTS   AGE
pod/helm-demo-apache-7c7dffd55b-d7xqr   1/1     Running   0          3m53s

NAME                       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
service/helm-demo-apache   NodePort    10.96.169.246   <none>        80:31850/TCP,443:31001/TCP   3m53s
service/kubernetes         ClusterIP   10.96.0.1       <none>        443/TCP                      8h

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/helm-demo-apache   1/1     1            1           3m53s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/helm-demo-apache-7c7dffd55b   1         1         1       3m53s

Access the Application outside Kubernetes Cluster

Since by default, service type for helm-demo is set to type ClusterIP, we need to change it to either LoadBalancer or NodePort. Alternatively, we can use port-forwarding to access the application.

Also as our setup is with Kind cluster, we need to specify one of the ports i.e. 31001 from extraPortMappings. We have already set this values inside helm parameters inside applicaton configuration. So we do not need to anything at this point.

We can point the browser to localhost:31001 and view the application: