5 Step Deploy to Kubernetes using Argo CD

Introduction

Embracing Kubernetes as your deployment platform offers numerous advantages for your applications, including dynamic scaling, efficient management of distributed components, and the ability to control different application versions. However, these benefits often come hand in hand with increased intricacies. Continuous Integration and Continuous Deployment (CI/CD) systems typically operate at a high level of abstraction, offering features like version control, change tracking, and rollback capabilities. One widely adopted approach to achieving this abstraction layer is known as GitOps.

GitOps, initially introduced by Weaveworks in a 2017 blog post, employs Git as the “single source of truth” for orchestrating CI/CD processes. It centralizes code changes within a shared repository per project and leverages pull requests for managing infrastructure and deployment tasks.

A variety of tools have emerged that place Git at the core of DevOps workflows within the Kubernetes environment. In this guide, we’ll delve into Argo CD, a declarative Continuous Delivery tool. Argo CD simplifies Continuous Delivery by automatically syncing and deploying applications whenever changes are detected within your GitHub repository. By overseeing application deployment and lifecycle processes, it addresses challenges related to version control, configurations, and application definitions within Kubernetes environments. It organizes intricate data using a user-friendly interface, capable of managing various types of Kubernetes manifests, including Jsonnet, Kustomize applications, Helm charts, and YAML/json files. Additionally, Argo CD seamlessly integrates webhook notifications from GitHub, GitLab, and Bitbucket.

Throughout this article, we will explore how to harness the power of Argo CD to synchronize and deploy applications directly from a GitHub repository.

For those interested in a managed Kubernetes hosting solution, be sure to explore our comprehensive managed Kubernetes service designed to accommodate your scalability needs.

Prerequisites

To follow this tutorial, you will need:

• An SSH key pair on your local Linux/MacOS/BSD machine. If you haven’t used SSH keys before, you can learn how to set them up by following this explanation of how to set up SSH keys on your local machine. If you are using Windows, you should be working in the Windows Subsystem for Linux environment.
• An existing Kubernetes cluster comprising at least one worker node. kubectl should be installed in your work environment and able to connect to your cluster. 
• Familiarity with Kubernetes concepts. Please refer to the article An Introduction to Kubernetes for more details.

Step 1 — Installing Argo CD

In order to install Argo CD, you should first have a valid Kubernetes configuration set up with kubectl, from which you can ping your worker nodes. You can test this by running kubectl get nodes:

kubectl get nodes

This command should return a list of nodes with the Ready status:

NAME                   STATUS   ROLES    AGE   VERSION
pool-uqv8a47h0-ul5a7   Ready    <none>   22m   v1.21.5
pool-uqv8a47h0-ul5am   Ready    <none>   21m   v1.21.5
pool-uqv8a47h0-ul5aq   Ready    <none>   21m   v1.21.5

If kubectl does not return a set of nodes with the Ready status, you should review your cluster configuration and the Kubernetes documentation.

Next, create the argocd namespace in your cluster, which will contain Argo CD and its associated services:

kubectl create namespace argocd

After that, you can run the Argo CD install script provided by the project maintainers.

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

watch kubectl get pods -n argocd

By default, there should be five pods that eventually receive the Running status as part of a stock Argo CD installation.

NAME                                  READY   STATUS    RESTARTS   AGE
argocd-application-controller-0       1/1     Running   0          2m28s
argocd-dex-server-66f865ffb4-chwwg    1/1     Running   0          2m30s
argocd-redis-5b6967fdfc-q4klp         1/1     Running   0          2m30s
argocd-repo-server-656c76778f-vsn7l   1/1     Running   0          2m29s
argocd-server-cd68f46f8-zg7hq         1/1     Running   0          2m28s

You can press Ctrl+C to exit the watch interface. You now have Argo CD running in your Kubernetes cluster! However, because of the way Kubernetes creates abstractions around your network interfaces, you won’t be able to access it directly without forwarding ports from inside your cluster. You’ll learn how to handle that in the next step.

Step 2 — Forwarding Ports to Access Argo CD

Because Kubernetes deploys services to arbitrary network addresses inside your cluster, you’ll need to forward the relevant ports in order to access them from your local machine. Argo CD sets up a service named argocd-server on port 443 internally. Because port 443 is the default HTTPS port, and you may be running some other HTTP/HTTPS services, it’s common practice to forward those to arbitrarily chosen other ports, like 8080, like so:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Port forwarding will block the terminal it’s running in as long as it’s active, so you’ll probably want to run this in a new terminal window while you continue to work. You can press Ctrl+C to gracefully quit a blocking process such as this one when you want to stop forwarding the port.

In the meantime, you should be able to access Argo CD in a web browser by navigating to localhost:8080. However, you’ll be prompted for a login password which you’ll need to use the command line to retrieve in the next step. You’ll probably need to click through a security warning because Argo CD has not yet been configured with a valid SSL certificate.

Step 3 — Working with Argo CD

For the next steps, you’ll want to have the argocd command installed locally for interfacing with and changing settings in your Argo CD instance. Argo CD’s official documentation recommends that you install it via the Homebrew package manager. Homebrew is very popular for managing command line tools on MacOS, and has more recently been ported to Linux to facilitate maintaining tools like this one.

If you don’t already have Homebrew installed, you can retrieve and install it with a one-line command:

​​/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

You may be prompted for your password during the installation process. Afterward, you should have the brew command available in your terminal. You can use it to install Argo CD:

brew install argocd

This in turn provides the argocd command. Before using it, you’ll want to use kubectl again to retrieve the admin password which was automatically generated during your installation, so that you can use it to log in. You’ll pass it a path to a particular JSON file that’s stored using Kubernetes secrets, and extract the relevant value:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

fbP20pvw-o-D5uxH

You can then log into your Argo CD dashboard by going back to localhost:8080 in a browser and logging in as the admin user with your own password:

Once everything is working, you can use the same credentials to log in to Argo CD via the command line, by running argocd login. This will be necessary for deploying from the command line later on:

argocd login localhost:8080

You’ll receive the equivalent certificate warning again on the command line here, and should enter y to proceed when prompted. If desired, you can then change your password to something more secure or more memorable by running argocd account update-password. After that, you’ll have a fully working Argo CD configuration. In the final steps of this tutorial, you’ll learn how to use it to actually deploy some example applications.

Step 4 — Handling Multiple Clusters (Optional)

Before deploying an application, you should review where you actually want to deploy it. By default, Argo CD will deploy applications to the same cluster that Argo CD itself is running in, which is fine for a demo, but is probably not what you’ll want in production. In order to list all of the clusters known to your current machine, you can use kubectl config:

kubectl config get-contexts -o name

test-deploy-cluster
test-target-cluster

Assuming that you’ve installed Argo CD into test-deploy-cluster, and you wanted to use it to deploy applications onto test-target-cluster, you could register test-target-cluster with Argo CD by running argocd cluster add:

argocd cluster add target-k8s

This will add the additional cluster’s login details to Argo CD, and enable Argo CD to deploy services on the cluster.

Step 5 — Deploying an Example Application (Optional)

Now that you have Argo CD running and you have an understanding of how to deploy applications to different Kubernetes clusters, it’s time to put it into practice. The Argo CD project maintains a repository of example applications that have been architected to showcase GitOps fundamentals. Many of these examples are ports of the same guestbook demo app to different kinds of Kubernetes manifests, such as Jsonnet. In this case, you’ll be deploying the helm-guestbook example, which uses a Helm chart, one of the most durable Kubernetes management solutions.

In order to do that, you’ll use the argocd app create command, providing the path to the Git repository, the specific helm-guestbook example, and passing your default destination and namespace:

argocd app create helm-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path helm-guestbook --dest-server https://kubernetes.default.svc --dest-namespace default

After “creating” the application inside of Argo CD, you can check its status with argocd app get:

argocd app get helm-guestbook

Name:               helm-guestbook
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          default
URL:                https://localhost:8080/applications/helm-guestbook
Repo:               https://github.com/argoproj/argocd-example-apps.git
Target:
Path:               helm-guestbook
SyncWindow:         Sync Allowed
Sync Policy:        <none>
Sync Status:        OutOfSync from  (53e28ff)
Health Status:      Missing

GROUP  KIND        NAMESPACE  NAME            STATUS     HEALTH   HOOK  MESSAGE
       Service     default    helm-guestbook  OutOfSync  Missing
apps   Deployment  default    helm-guestbook  OutOfSync  Missing

The OutOfSync application status is normal. You’ve retrieved the application’s helm chart from Github and created an entry for it in Argo CD, but you haven’t actually spun up any Kubernetes resources for it yet. In order to actually deploy the application you’ll run argocd app sync:

argocd app sync helm-guestbook

sync is synonymous with deployment here in keeping with the principles of GitOps – the goal when using Argo CD is for your application to always track 1:1 with its upstream configuration.

TIMESTAMP                  GROUP        KIND   NAMESPACE                  NAME    STATUS    HEALTH        HOOK  MESSAGE
2022-01-19T11:01:48-08:00            Service     default        helm-guestbook  OutOfSync  Missing
2022-01-19T11:01:48-08:00   apps  Deployment     default        helm-guestbook  OutOfSync  Missing
2022-01-19T11:01:48-08:00            Service     default        helm-guestbook    Synced  Healthy
2022-01-19T11:01:48-08:00            Service     default        helm-guestbook    Synced   Healthy              service/helm-guestbook created
2022-01-19T11:01:48-08:00   apps  Deployment     default        helm-guestbook  OutOfSync  Missing              deployment.apps/helm-guestbook created
2022-01-19T11:01:49-08:00   apps  Deployment     default        helm-guestbook    Synced  Progressing              deployment.apps/helm-guestbook created

Name:               helm-guestbook
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          default
URL:                https://localhost:8080/applications/helm-guestbook
Repo:               https://github.com/argoproj/argocd-example-apps.git
Target:
Path:               helm-guestbook
SyncWindow:         Sync Allowed
Sync Policy:        <none>
Sync Status:        Synced to  (53e28ff)
Health Status:      Progressing

Operation:          Sync
Sync Revision:      53e28ff20cc530b9ada2173fbbd64d48338583ba
Phase:              Succeeded
Start:              2022-01-19 11:01:49 -0800 PST
Finished:           2022-01-19 11:01:50 -0800 PST
Duration:           1s
Message:            successfully synced (all tasks run)

GROUP  KIND        NAMESPACE  NAME            STATUS  HEALTH       HOOK  MESSAGE
       Service     default    helm-guestbook  Synced  Healthy            service/helm-guestbook created
apps   Deployment  default    helm-guestbook  Synced  Progressing        deployment.apps/helm-guestbook created

You have now successfully deployed an application using Argo CD! It is possible to accomplish the same thing from the Argo CD web interface, but it is usually quicker and more reproducible to deploy via the command line. However, it is very helpful to check on your Argo CD web dashboard after deployment in order to verify that your applications are running properly. You can see that by opening localhost:8080 in a browser:

At this point, the last thing to do is to ensure you can access your new deployment in a browser. To do that, you’ll forward another port, the way you did for Argo CD itself. Internally, the helm-guestbook app runs on the regular HTTP port 80, and in order to avoid conflicting with anything that might be running on your own port 80 or on the port 8080 you’re using for Argo CD, you can forward it to port 9090:

kubectl port-forward svc/helm-guestbook 9090:80

As before, you’ll probably want to do this in another terminal, because it will block that terminal until you press Ctrl+C to stop forwarding the port. You can then open localhost:9090 in a browser window to see your example guestbook app:

Any further pushes to this Github repository will automatically be reflected in ArgoCD, which will resync your deployment while providing continuous availability.

Conclusion

In summary, you have gained insights into the core aspects of setting up and launching applications via Argo CD. Given the multifaceted nature of Kubernetes, maintaining the viability of your deployments is of paramount importance, making the adoption of the GitOps methodology a valuable choice.

Moving forward, an intriguing avenue of exploration involves mastering the deployment of TOBS, The Observability Stack. This empowers you with the capability to monitor the health, uptime, and logging aspects of your Kubernetes cluster in a comprehensive manner.