Getting Started with GitOps and ArgoCD — 1

Gitops and ArgoCD Icon

GitOps

The discussion of GitOps almost always and naturally begins with its foundation: DevOps. The DevOps movement was born out of the need to automate application delivery, enabling the teams that write, ship, and support software to work together toward a common goal. DevOps is not necessarily a specific department; it is a culture within your organization. So, what is the relationship between GitOps and DevOps? It’s actually quite simple: GitOps is DevOps. GitOps is the natural evolution of DevOps, translating the best practices that DevOps practitioners already advocate into a standardized infrastructure practice.

When you research the term GitOps, you will likely come across many seemingly unrelated concepts. So, is GitOps a tool used by application developers, a way for infrastructure teams to manage their environments, or simply a new name for continuous integration/continuous deployment (CI/CD) pipelines?

Simply put, GitOps is a declarative methodology that treats Git as the “Single Source of Truth” for infrastructure and application management. It advocates that any configuration changes in systems like Kubernetes or Terraform should never be made manually on the servers, but exclusively by updating the code in Git. Furthermore, GitOps ensures the continuous reconciliation between this desired state defined in Git and the actual, current state of the system.

GitOps Principles

1. Declarative A system managed by GitOps must have its desired state expressed declaratively. This means instead of telling the system step-by-step “how” to operate, we define “what the final state” should be. This approach is exactly identical to the inherent declarative nature of Kubernetes itself.

2. Versioned & Immutable The desired state of the system must be stored in a way that is trackable, versionable, and immutable. The best industry standard for this principle is Git. Every configuration change is saved as a new version (commit), and past versions remain intact. This ensures the entire history of the system is preserved, allowing for safe rollbacks to a previous version when necessary.

3. Pull-Based Automation Software agents must automatically pull the desired state declarations from the source. This is exactly where GitOps diverges from traditional CI/CD processes. Instead of “pushing” changes to the system via an external trigger using a CI tool, agents periodically poll the Git repository and pull any new changes into the environment. This approach is significantly more secure as it does not require external access to the cluster. In the system architecture, tools like ArgoCD or Flux typically assume the role of this “software agent.”

4. Continuous Reconciliation The agents in the system continuously observe the “current state” of the live environment against the “desired state” defined in Git. If someone manually intervenes in the system (for example, using kubectl edit) or if any divergence (drift) is detected between these two states, the agents automatically work to synchronize the live system back to the state defined in Git. GitOps takes this reconciliation process—which Kubernetes controllers perform for single objects—and makes it continuous across the entire application and infrastructure stack.

Why Argo CD?

Traditional, event-driven (push-based) deployment methods struggled to align with the declarative nature of Kubernetes. The primary reason DevOps experts have so widely adopted Argo CD is that it perfectly complements this architecture. However, the practical advantages that truly make Argo CD an industry standard are as follows:

• Advanced Web Interface (UI) and Visualization: Understanding what is happening behind the scenes in the GitOps world can sometimes be difficult. With its user-friendly interface, Argo CD instantly visualizes the state of resources within Kubernetes (such as Deployments, Services, Ingresses, etc.) and any differences (drift) between the Git repository and the live environment.
• Kubernetes-Native Architecture: Argo CD is not an external server connecting to your system; it is a native component (operator) running directly within your Kubernetes cluster. This enables it to directly leverage Kubernetes’ inherent capabilities and CRD (Custom Resource Definition) structures.
• High-Level Security (Pull-Based Model): In the past, CI/CD servers (such as Jenkins) required broad permissions (admin privileges) to deploy applications to Kubernetes. Because Argo CD runs inside the cluster and only “reads” the Git repository, there is no need to grant inbound access credentials or punch holes in your firewall.
• Self-Healing and Fast Rollbacks: If a manual intervention occurs in the live environment (for example, someone logs into the server and messes up the configuration), Argo CD can instantly detect this and revert it to the correct state defined in Git (Self-Healing). In the event of a deployment issue, it allows you to restore the entire application to a previous stable state in seconds simply by reverting to an older version (commit) via Git, avoiding any complex rollback procedures.
• Multi-Cluster Management: Argo CD enables you to manage not just the cluster where it is installed, but dozens of different Kubernetes clusters simultaneously from a single, centralized control plane.

Introduction to Argo CD

Kubernetes has caused a major disruption in the tech industry. Its role as the cornerstone of the entire cloud-native ecosystem cannot be overstated. The Cloud Native Computing Foundation (CNCF) was founded with Kubernetes at its core, and as a result, numerous open-source tools have been developed around the principle of leveraging Kubernetes’ immutable and declarative nature.

As the popularity and adoption of Kubernetes grew, the cloud-native ecosystem expanded as a whole. The need to support diverse use cases paved the way for the development of Kubernetes-native projects, tools, and various initiatives required to further accelerate the adoption of Kubernetes and cloud-native architectures.

What Is Argo CD?

Argo CD is an open-source Continuous Delivery (CD) tool designed to implement GitOps principles on Kubernetes.

It operates as a controller within Kubernetes. Its role is quite simple: it continuously monitors and compares the “Desired State” defined in your Git repository against the “Live State” currently running in your Kubernetes cluster.

Argo CD Architecture

Argo CD’s architecture is designed entirely in line with the cloud-native nature of Kubernetes itself. Instead of being an externally connected server, it is installed directly inside your Kubernetes cluster as a set of Deployments and Services.

Overall Argo CD architecture(Argo CD: Up and Running)

1. API Server This is the system’s gateway to the outside world. Whether you use Argo CD’s sleek web interface (UI), run CLI commands from the terminal, or send requests via a CI tool; they all communicate with the API Server first.

• Manages Authentication processes.
• Handles commands such as creating applications, deleting them, or triggering manual synchronizations.
• Enforces RBAC (Role-Based Access Control) to verify what actions users or services are authorized to perform.

2. Repository Server (Repo Server) This is the component that communicates directly with your Git repositories (or Helm repos). It acts as a sort of “translator.”

• The files you store in Git may not always be in pure YAML format (they could be Helm Charts or Kustomize configurations).
• The Repo Server pulls these files from Git, compiles them (for example, by running helm template in the background), and converts them into pure Kubernetes manifests (YAML) that the Application Controller can understand.
• Caches Git repositories locally to improve performance.

3. Application Controller This is the actual “brain” and workhorse of the system. It operates on the classic Kubernetes Controller logic and runs a continuous reconciliation loop.

• Continuously monitors the current state of the live system (Live State).
• Receives the Desired State from the Repository Server.
• Compares these two states. If there is a difference (drift) between the code in Git and the live environment, it marks the application’s status as OutOfSync.
• If the Auto-Sync feature is enabled, it instantly applies the updated state from Git to the live cluster.

Argo CD Installing

We will deploy Argo CD in our Kubernetes environment using Helm. To do this, you can either set up a local Kubernetes cluster on your own machine using Minikube, or you can provision one on a cloud provider. Since the main focus of this article is Argo CD, I will leave the Kubernetes installation steps to you.

First, let’s create a dedicated namespace for Argo CD on Kubernetes.

kubectl create ns argocd

First, add the Argo CD Helm repository:

helm repo add argo https://argoproj.github.io/argo-helm

Install the Helm chart using the default configuration and create a new namespace called argocd using the following command:

helm upgrade -i argo-cd argo/argo-cd -n argocd --create-namespace

Now, let’s run the following command to verify if Argo CD has been successfully installed:

kubectl get pods -n argocd

kubectl get pods -n argocd

You can gain access to Argo CD by connecting to its user interface. To do this, run the following command to forward port 8081 from your local machine to the Argo CD API server service, which will grant you access to the UI:

kubectl port-forward svc/argo-cd-argocd-server -n argocd 8081:443

After running the command, you can navigate to https://localhost:8081/ in your browser to access the Argo CD UI.

ArgoCD ui

Now that we have opened the UI, we need to log into Argo CD. To do this, we need a username and a password. The default username for Argo CD is admin. To retrieve the password, you need to run the following command in your terminal:

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

Once you log into Argo CD, you will be greeted by the following screen:

ArgoCD Application UI

If you’ve stayed with me this far, it means we have made a solid entry into the world of GitOps and Argo CD. In the next article of this series, we will put theory into practice, dive deep into Argo CD, and deploy our very first application.

Thank you so much for reading! You can follow along to stay updated on future articles, and if you’d like to show your support, feel free to leave some claps. See you in the next post!

Linkedln → www.linkedin.com/in/tuğrulhan-karslı-9683b7256