Kubernetes Basics #9 - ArgoCD

DevOps

Last Edited: 6/13/2025

This blog post introduces ArgoCD in Kubernetes.

DevOps

In the previous article, we discussed monitoring in Kubernetes as a use case of service accounts. Another prominent use case of service accounts, which we briefly mentioned, is build tools. Hence, in this article, we will cover the basics of ArgoCD, a popular build tool for Kubernetes.

Why ArgoCD?

In a standard CI/CD pipeline (using GitHub, GitLab, Jenkins, etc.) when working on a project involving a Kubernetes cluster, setting up CD can be challenging. It requires a way for the pipeline to access the Kubernetes cluster and run kubectl apply, which presents security challenges, especially when deploying on remote servers managed by a cloud provider. Furthermore, traditional build tools often lack real-time visibility into the deployment status, hindering synchronization between the current and desired states.

ArgoCD addresses these issues by enabling easier, more efficient, and more secure CD pipelines for Kubernetes based on GitOps. It tracks changes in a Git repository and automatically applies them to the cluster, ensuring it always matches the desired state defined within the repository. By leveraging Git, it provides a familiar interface for making changes to the clusters, ensuring proper versioning and facilitating smooth collaboration. Access control is simplified because ArgoCD resides within the cluster and can be managed as a service account (already set up by default). Developers can then utilize Git access controls.

The pull model also prevents untracked changes from being made to the cluster and supports disaster recovery. Combining these benefits with ArgoCD's declarative configuration using YAML files and its well-designed and informative graphical user interface, ArgoCD is a preferred build tool for Kubernetes projects that can eliminate the need for complicated access control and health probe setups.

Setting Up ArgoCD

To set up ArgoCD, you can follow the instructions in the ArgoCD official documentation (cited below). The process essentially involves creating an argocd namespace and applying the necessary resources using kubectl apply. After installation, verify the successful creation of services using kubectl get and access the user interface by port forwarding the argocd-server using kubectl port-forward (you may encounter a warning about an insecure connection, which can be safely ignored).

application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-argo-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example-usr/example-cluster-config.git # Git URL to pull from
    targetRevision: HEAD # Last Commit
    path: dev # file to track
  destination:
    server: https://kubernetes.default.svc # Internal service name of API server
    # (When running ArgoCD for external cluster, we specify the external address of API server.)
    namespace: myapp
  syncPolicy:
    syncOptions:
      - CreateNamespace=true # create namespace ('myapp' in this case) when 'myapp' doesn't exist
    automated:
      selfHeal: true # make sure manual changes are healed
      prune: true # delete resources that are no longer necessary

We can login to the user interface using the username admin and the password stored in the argocd-install-admin-secret (the password is base64 encoded, so decode it using echo <password> | base64 --decode). The example YAML file provided above demonstrates ArgoCD configuration. It assumes the default polling mechanism, where ArgoCD checks the repository every 3 minutes, but you can configure a webhook for immediate reflection of changes. Applying this YAML using kubectl apply will automatically set up the application that applies and creates all resources defined in the dev file of the repository.

You can confirm that changes are tracked and applied automatically by modifying resource configurations in the repository, that manual changes to the cluster are reverted by ArgoCD by applying changes manually (defined with selfHeal: true), and that unnecessary resources are deleted by reducing the number of pod replicas in the repository (defined with sprune: true). ArgoCD also offers various prebuilt features helpful for setting up a production-ready Kubernetes cluster, such as OIDC authentication to the user interface, Helm integration, and /metrics endpoint exposed for Prometheus by default. I recommend checking the official documentation (cited below) for these features and other useful information.

Conclusion

In this article, we covered what ArgoCD (& GitOps) is, why ArgoCD is useful, and the basics of how to use it. It greatly simplifies CI/CD, access control, and health monitoring and disaster recovery, so I recommend learning it further by reading the official documentation and other resources (cited below) and trying to use it whenever appropriate.

Resources

Back to Top↑