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 fifth 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 Kustomize Manifests with Argo CD

Kustomize is a configuration management tool for the Kubernetes ecosystem. Kustomize is a declarative templating engine which works off a concept of refactoring Kubernetes manifests. It allows you to mix and match already written Kubernetes manifests and overrides optional attributes in a simple yaml file called Kustomization files. You can also use overlays files where you can override other Kustomization files and Kubernetes manifests.

Kustomize is available natively since Kubectl v1.14 and also available as a standalone binary for extension and integration into other services.

Create an Application from a GitHub Repository

As always, it all starts with defining an application. For purpose of this post, we’ll use example repository at https://github.com/goyalmohit/argocd-example-apps/tree/master/kustomize-guestbook.

To start, click the + NEW APP button and fill the upcoming form. After that, we need to submit fields 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 guestbook-ui 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.

Argo CD has a thoughtful UI and using auto-population helps in removing manual errors and guesswork. We’ll see the same for many fields listed in various forms.

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

Repository URL – Provide the url for the GitHub repository containing the application manifests. We can add private as well as public repositories. For private repositories, you’ll need to provide additional details related to the authentication. Since our repository is a public one, we do not need to provide additional details.

Revision – You can choose to provide the specific branch or tag for github repo and sync the same state with Kubernetes details. We’ll leave it as HEAD so that it can get latest commits at various points in the time and compare them with the application state inside the Kubernetes cluster.

Path – This helps in further segregating application manifests inside the GitHub repository. We can ask it to read only specific directories in the repository and read manifests within that path. We’ll select this as kustomize-guestbook.

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.

At this point, Argo CD will read the Kustomization.yaml file present in the path and will prompt us to allow override with different values. For our use case, we’ll go with the default configuration mentioned in the github repo:

After filling out the information above, click Create at the top of the UI to create the guestbook-ui 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.

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:

For now, we’ll leave the default options and select synchronize button. After this, it will fetch latest state of HEAD before proceeding further and then starts applying the same:

Once the manifests are applied, we can review the application health and resources deployed. As we mentioned in the Kustomization.yaml file, we can see that each resource name is prefixed by kustomize-:

Here we can lot of nice details such as health of resources, their revisions, when they were deployed, sync state etc. There is also 3 dots in front of each tile, which can be used to selectively sync/delete/manage the resource, or view logs, as applicable to the resource type.

We can also view the same details with kubectl:

mohitgoyal@desktop:/mnt/d/mohit/src/kind$ kubectl get all -n default
NAME                                          READY   STATUS    RESTARTS   AGE
pod/kustomize-guestbook-ui-779bc8b498-rbl4k   1/1     Running   0          93s

NAME                             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/kubernetes               ClusterIP   10.96.0.1       <none>        443/TCP   41m
service/kustomize-guestbook-ui   ClusterIP   10.96.112.200   <none>        80/TCP    93s

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/kustomize-guestbook-ui   0/1     1            0           93s

NAME                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/kustomize-guestbook-ui-779bc8b498   1         1         0       93s

Access the Application outside Kubernetes Cluster

Since service type for guestbook-ui 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. Lets edit service configuration with kubectl edit svc -n default guestbook-ui and save the changes.

Once its done, we can point the browser to localhost:31001 and view the application: