Declarative GitOps with Argo CD

Managing Kubernetes applications can become complex when environments shift and manual updates lead to drift. According to the official documentation, Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes that addresses this problem by moving the source of truth entirely into version control.

The GitOps Philosophy

Argo CD operates under the principle that Application definitions, configurations, and environments should be declarative and version controlled. Furthermore, Application deployment and lifecycle management should be automated, auditable, and easy to understand.

By adopting this operational model, Argo CD follows the GitOps pattern of using Git repositories as the source of truth for defining the desired application state. It then strictly enforces this by ensuring that Argo CD automates the deployment of the desired application states in the specified target environments. Because everything is stored in Git, any divergence between your live cluster and your repository is immediately detectable. To support reliable rollbacks and predictable releases, Application deployments can track updates to branches, tags, or be pinned to a specific version of manifests at a Git commit.

Installing Argo CD on Kubernetes

Before you begin, ensure you have the kubectl command-line tool installed and configured with a valid kubeconfig file.

To install Argo CD, you will first create a dedicated namespace. Then, you apply the installation manifest from the stable branch. Because the project includes comprehensive Custom Resource Definitions (CRDs), you must use specific flags during the deployment.

Run the exact official setup commands provided in the getting started guide:

When applying this manifest, The --server-side flag is required because some Argo CD CRDs (like ApplicationSet) exceed the 262KB annotation size limit imposed by client-side kubectl apply. By utilizing server-side apply, the cluster avoids storing the massive configuration annotation locally, which bypasses the size restriction. The force-conflicts flag ensures that the installation can cleanly take ownership of the necessary fields.

Exposing the Argo CD Server

Once the resources are deployed into the argocd namespace, the controller begins its lifecycle. However, for security reasons, The default installation will have a self-signed certificate and cannot be accessed without a bit of extra work. Furthermore, By default, Argo CD isn’t exposed outside the cluster.

To interact with the Argo CD UI or the command-line interface remotely, you will likely need to expose the service. If you are operating within a cloud environment that supports load balancers, you can change the argocd-server service type to LoadBalancer.

Execute the following command to patch the service as shown in the installation documentation:

After a short wait, your cloud provider will assign an external IP address to the service. You can then retrieve this IP and access the web-based user interface securely. Even after exposing the service, keep in mind that the initial setup relies on a self-signed certificate, so your client might display a warning until a trusted certificate is installed.