Learn GitOps with ArgoCD - GitOps Ecosystem & ArgoCD Overview
The competitive landscape of GitOps tools, why ArgoCD became the industry standard, its component architecture, core concepts, and how the reconciliation loop always keeps the cluster in check.
#Introduction
In episode 1 we understood why GitOps exists: Git as the single source of truth, the pull model, and reconciliation. Now it's time to get to know the players. Like choosing a framework, the decision to pick a GitOps tool shouldn't be based on hype — you need to know the competitive landscape, the strengths of each, and the reasons why ArgoCD is the choice we study in this series.
In this episode we'll cover the GitOps tool landscape, the reasons for choosing ArgoCD, its component architecture, the core concepts we'll keep using throughout this series, and how the reconciliation loop works — the engine that makes GitOps actually run.
#The GitOps Tool Landscape
Several dominant tools occupy the GitOps space for Kubernetes. Each was born from a different philosophy:
- ArgoCD — pull-based, a fully declarative Kubernetes operator developed by Intuit, now one of the most active projects in the CNCF.
- Flux CD — pull-based, developed by Weaveworks (the ones who coined the term GitOps), built on GitRepository + Kustomization resources.
- Jenkins X — based on CI/CD pipelines with a GitOps workflow layered on top; better suited for teams that want a single tool for both CI and CD.
- GitLab CI/CD with GitOps — uses GitLab pipelines to manage a GitOps agent (requires integration with Flux/ArgoCD or the GitLab Agent feature).
A quick comparison:
| Aspect | ArgoCD | Flux CD | Jenkins X |
|---|---|---|---|
| Model | Pull | Pull | Push + GitOps |
| Built-in CI | No | No | Yes (Tekton) |
| Web UI | Very rich | Basic (optional) | Dashboard |
| Multi-cluster | Yes | Yes | Yes |
| Sync engine | Per Application app | Kustomization | Pipeline |
| Focus | CD + observability | Lightweight CD | End-to-end pipeline |
#Why ArgoCD?
There are many reasons ArgoCD became the default choice of the modern world:
- CNCF graduated — passed CNCF incubation as a stable project; a signal of maturity and serious governance.
- Kubernetes-native — ArgoCD is an operator that lives as CRDs; it understands Deployment, Service, Ingress, even custom CRDs of your applications.
- Multi-cluster — a single ArgoCD instance can manage many clusters from one point.
- Rich UI — application visualization, resource tree view, diff, and logs directly from the browser.
- Active community — regular releases, many contributors, a large ecosystem (ApplicationSet, Rollouts, Image Updater, Notifications).
- Widespread enterprise adoption — used by hundreds of companies; meaning lots of runbooks, examples, and practitioners to help you.
- Complete feature set — sync strategies, hooks, sync waves, projects, RBAC, and SSO in a single package.
Tip
The strongest argument for ArgoCD isn't "it's the most popular," but that features that normally require many additional tools (canary deployment, automatic image updates, notifications) are already available in one ecosystem. This simplifies your operational stack.
#ArgoCD Architecture
After installation, ArgoCD runs as a set of pods in the argocd namespace. Let's look at its components:
kubectl get pods -n argocd
argocd-application-controller-0 1/1 Running
argocd-applicationset-controller-.. 1/1 Running
argocd-dex-server-.. 1/1 Running
argocd-notifications-controller-.. 1/1 Running
argocd-redis-.. 1/1 Running
argocd-repo-server-.. 1/1 Running
argocd-server-.. 1/1 RunningThe role of each component:
| Component | Role |
|---|---|
| API Server (argocd-server) | Gateway for all interactions: gRPC/REST API, web UI, and CLI |
| Repository Server (argocd-repo-server) | Clones and renders manifests from Git (Helm/Kustomize/Jsonnet) |
| Application Controller (argocd-application-controller) | The reconciliation brain: compares & reconciles state |
| Redis | Caches render results and state for performance |
| Dex | SSO/OIDC provider for authentication (can be replaced with another provider) |
| Application CRDs | Application, Project, ApplicationSet objects stored in the kube-apiserver |
#Core Concepts
Before the hands-on part, master the terms we'll use over and over:
| Concept | Explanation |
|---|---|
| Application | The core unit of work: one Git source + one destination cluster/namespace |
| Project | A logical container to restrict Applications (repo, cluster, namespace whitelist) |
| Repository | Registration of accessible Git URLs (HTTPS token or SSH key) |
| Cluster | The deployment target; in-cluster or an external cluster |
| Sync status | Cluster position vs Git: Synced, OutOfSync, Unknown |
| Health status | Operational condition: Healthy, Progressing, Degraded, Suspended |
| Sync strategies | How ArgoCD applies changes: manual vs automated |
Note
Don't mix them up: Sync status answers "is the cluster the same as Git?", while Health status answers "is the application running healthily?" An application can be Synced (matches Git) but Degraded (CrashLoopBackOff). These two dimensions are independent of each other.
#How It Works: The Reconciliation Loop
ArgoCD applies the reconciliation principle like Kubernetes:
- Read the desired state from Git (via the Repository Server that renders manifests).
- Compare it with the actual state in the cluster via the kube-apiserver.
- Sync (if allowed by the sync policy) — apply, delete, or fix resources.
- Assess the health of the synced resources.
- Repeat every reconciliation interval (3 minutes by default) and on events (Git webhooks, manual changes).
argocd app get api
Health Status: Healthy
Sync Status: SyncedWhen you git commit and git push changes, ArgoCD (via webhook or on the next cycle) detects the mismatch and marks the Application OutOfSync. With an automated sync policy, it reconciles immediately; without one, it waits for manual approval — we'll practice both in episodes 6 and 7.
#Closing
This episode maps the GitOps landscape and opens up the ArgoCD engine:
- Main tools: ArgoCD (pull), Flux (pull), Jenkins X (push + GitOps), GitLab CI/CD.
- ArgoCD excels: CNCF graduated, k8s-native, multi-cluster, rich UI, complete ecosystem.
- Components: API Server, Repository Server, Application Controller, Redis, Dex, CRDs.
- Core concepts: Application, Project, Repository, Cluster, Sync & Health status.
- The reconciliation loop keeps the cluster aligned with Git.
In episode 3 we'll refresh Kubernetes fundamentals and manifest management: a review of Pod, Deployment, Service, ConfigMap, Secret, and Ingress, then an introduction to Helm and Kustomize — the two main weapons for writing clean manifests before diving into ArgoCD practice. See you there!