Argo CD and GitOps: A Practical Guide to Kubernetes Deployment in 2026

If you manage Kubernetes workloads today, you have probably heard the term GitOps thrown around like it is a magic wand. The idea is simple: your cluster state should be driven entirely by Git. Change manifests in Git, and the cluster follows. But between theory and production, there are plenty of pitfalls. Argo CD has emerged as the de facto standard for GitOps-based continuous delivery on Kubernetes, and this guide walks you through what actually matters when setting it up.

What Is GitOps, Really?

GitOps is not just version-controlled YAML files. It is a operational model built on two core principles: declarative infrastructure and pull-based automation. Your desired state lives in Git. A controller inside the cluster watches for changes and reconciles the live state to match. No one ships directly to the cluster with kubectl apply anymore — well, at least not after you adopt this properly.

Argo CD implements this model by continuously monitoring the Git repository and applying any drift it detects. It supports Helm charts, Kustomize, plain YAML, and even custom resource definitions. This flexibility means you can migrate existing deployments without rewriting everything from scratch.

Getting Argo CD Installed

The fastest way to get started is the official install manifest:

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

After installation, grab the admin password with:

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

Log in via the web UI or CLI using argocd login. The default Argo CD port is 8080, so expose it with a NodePort service or an Ingress if you need external access.

The Application of Apps Pattern

One of the most powerful patterns in Argo CD is Application of Apps. Instead of managing dozens of individual Applications manually, you create a top-level Application that points to a directory containing other Application manifests. This is like a meta-configuration layer.

For example, your Git repo could have this structure:

applications/
  frontend/
    app.yaml
  backend/
    app.yaml
  monitoring/
    app.yaml
root-application.yaml

The root-application.yaml references the applications/ directory, and Argo CD recursively creates all child Applications. This scales beautifully as your platform grows.

Synchronization Strategies

Argo CD offers several sync strategies that control how changes are applied:

• Sync — the default. Replaces live state to match Git.
• Prune — deletes resources no longer in Git. Dangerous if you forget what is tracked.
• Server-side apply — uses Kubernetes server-side apply for smarter field merging. Preferred over client-side apply.

For zero-downtime deployments, combine Argo CD with a rolling update strategy in your Deployment manifests. Set strategy.type: RollingUpdate and maxSurge: 25% to keep traffic flowing while pods rotate.

Handling Secrets Securely

Storing secrets in Git can be tempting but risky. Argo CD provides several approaches:

1. External Secrets Operator — integrates with AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager. Manifests reference the secret name; the operator fetches and injects the value.
2. Sealed Secrets — encrypt secrets in Git so only your cluster can decrypt them.
3. Kubernetes Secrets Store CSI Driver — mounts secrets as volumes at runtime without storing anything in Git.

Never commit plaintext passwords to your repo. Even with private repositories, a misconfigured branch policy or accidental push creates an audit nightmare later.

Multi-Cluster Management

One of Argo CD's real strengths is managing multiple clusters from a single control plane. Register clusters with:

argocd cluster add production-cluster --name prod-us-east
argocd cluster add staging-cluster --name staging-eu

Then tag Applications to specific clusters using labels. This is invaluable for teams running the same stack across environments without duplicating configuration.

Troubleshooting Common Issues

Even with a solid setup, things go wrong. Here are the usual suspects:

• Sync windows blocking deployments — Argo CD sync windows restrict when Applications can sync. Check your cluster and Application-level window configs if a deployment is stuck in "Pending."
• RBAC denials — Argo CD uses its own RBAC system alongside Kubernetes RBAC. Verify the .argocd-rbac-policy.yaml configmap grants access to your users and groups.
• Helm value overrides conflicts — when using Helm, ensure your values.yaml does not override fields managed by Kustomize patches. Use a single tool per Application where possible.

Observability and Alerts

A GitOps workflow without observability is flying blind. Argo CD exposes Prometheus metrics on port 9090. Key metrics to watch include argocd_app_sync_total, argocd_app_info, and argocd_cluster_connected. Set up Grafana dashboards for these, and configure alerting rules that fire when an Application is out of sync for more than five minutes.

Wrapping Up

Argo CD has become the backbone of Kubernetes CI/CD pipelines in 2026 because it brings real GitOps discipline to deployment workflows. The key takeaways: use the Application of Apps pattern to scale, handle secrets with an external provider, and never skip observability. Your future self — and your on-call rotation — will thank you.

If you are still applying manifests manually to your clusters, it is time to make the shift. GitOps is not just a buzzword; it is the foundation of reliable, auditable infrastructure at scale.