What Is GitOps
GitOps is an operational model where Git is the single source of truth for your infrastructure and application configuration. Every change to your Kubernetes cluster -- deployments, config changes, scaling -- is made through a Git commit, reviewed via a pull request, and automatically applied by a GitOps controller.
The benefits are compelling: full audit trail, easy rollbacks, declarative configuration, and reduced human error. ArgoCD is the most widely adopted GitOps tool for Kubernetes.
Why ArgoCD
Several GitOps tools exist (Flux, Jenkins X, Rancher Fleet), but ArgoCD has become the de facto standard for good reasons:
Visual dashboard: ArgoCD provides a web UI showing the sync status of every application, resource health, and deployment history. This is invaluable for operations teams.
Multi-cluster support: Manage deployments across multiple Kubernetes clusters from a single ArgoCD instance.
Application of Applications pattern: Define your entire platform as a hierarchy of ArgoCD Applications, enabling scalable management.
Sync policies: Configure automatic or manual sync, with options for self-healing (automatically reverting manual changes) and pruning (removing resources no longer defined in Git).
SSO integration: ArgoCD integrates with OIDC, SAML, LDAP, and GitHub/GitLab for authentication.
Core Concepts
Application
An ArgoCD Application defines: - Source: A Git repository containing Kubernetes manifests (plain YAML, Helm charts, or Kustomize overlays) - Destination: The target Kubernetes cluster and namespace - Sync policy: Automatic or manual, with self-heal and prune options
Sync Status
ArgoCD continuously compares the desired state (Git) with the actual state (cluster): - Synced: Cluster matches Git -- everything is correct - OutOfSync: Cluster differs from Git -- a sync is needed - Unknown: ArgoCD cannot determine the status
Health Status
Beyond sync status, ArgoCD monitors resource health: - Healthy: All resources are running correctly - Degraded: Some resources have issues (pod crashes, failed deployments) - Progressing: A deployment is in progress - Missing: Expected resources do not exist in the cluster
Repository Structure
Recommended Layout
Organize your GitOps repositories for clarity and scalability:
- A dedicated GitOps repo (separate from application source code)
- Directory structure organized by environment and application
- Base configurations with environment-specific overlays using Kustomize
- Helm values files per environment for Helm-based applications
Environment Promotion
Promote changes through environments using Git: 1. Merge to the dev branch -- ArgoCD deploys to the dev cluster 2. Create a PR from dev to staging -- ArgoCD deploys to staging after merge 3. Create a PR from staging to production -- ArgoCD deploys to production after merge and approval
Each promotion is a Git merge with full review history.
Deployment Strategies with ArgoCD
Rolling Updates
The default strategy: Kubernetes gradually replaces old pods with new ones. ArgoCD monitors the rollout and reports health status throughout the process.
Blue-Green Deployments
Using ArgoCD with Argo Rollouts: - Deploy the new version alongside the old version - Run smoke tests against the new version - Switch traffic from old to new atomically - Keep the old version available for instant rollback
Canary Deployments
Gradually shift traffic to the new version: - Start with 5% of traffic to the canary - Monitor error rates and latency - Incrementally increase traffic (25%, 50%, 100%) - Automatically roll back if metrics degrade
Security Best Practices
RBAC
Configure ArgoCD RBAC to control who can: - View applications (read-only for most team members) - Sync applications (deployment permissions for team leads) - Modify ArgoCD configuration (admin-only) - Access specific projects or clusters
Secret Management
Never store secrets in Git. Instead: - Use Sealed Secrets (encrypt secrets that can only be decrypted in-cluster) - Use External Secrets Operator to sync from Vault, AWS Secrets Manager, or Azure Key Vault - Use SOPS (Secret Operations) for encrypted secret files in Git
Network Policies
- Restrict ArgoCD server access to authorized networks
- Use TLS for all ArgoCD communication
- Limit ArgoCD's cluster permissions to only the namespaces it manages
Monitoring ArgoCD
Key Metrics to Track
- Sync success/failure rate per application
- Time from Git commit to cluster deployment
- Number of OutOfSync applications (should be zero or near-zero)
- ArgoCD controller resource usage and queue depth
Alerting
Configure alerts for: - Applications stuck in OutOfSync state for more than 10 minutes - Failed sync operations - Applications in Degraded health status - ArgoCD component health (server, controller, repo-server)
Getting Started
- Day 1: Install ArgoCD on your Kubernetes cluster
- Week 1: Migrate one non-critical application to GitOps
- Week 2: Add SSO integration and RBAC configuration
- Week 3: Expand to staging and production environments
- Month 2: Implement canary deployments with Argo Rollouts for critical services
Scaling ArgoCD for Enterprise Environments
Running ArgoCD for a handful of applications is straightforward. Scaling it to manage hundreds of applications across multiple clusters requires deliberate architectural decisions.
The App of Apps Pattern
Instead of manually creating each ArgoCD Application, define a root Application that points to a directory of Application manifests. When you add a new application, you simply add a YAML file to that directory, and ArgoCD automatically picks it up. This pattern enables self-service -- teams can onboard new applications by submitting a pull request to the GitOps repository.
ApplicationSets for Dynamic Environments
ArgoCD ApplicationSets take the App of Apps pattern further. They allow you to generate Applications dynamically based on templates and generators:
- Git generator: Create an Application for every directory in a Git repository -- useful when each team has their own directory
- Cluster generator: Deploy the same application across all registered clusters automatically
- Pull request generator: Spin up preview environments for every open pull request, then clean them up when the PR is merged
ApplicationSets are essential for organizations managing dozens of microservices or clusters. Without them, Application manifest maintenance becomes its own operational burden.
Multi-Tenancy and Project Isolation
In enterprise environments, different teams should not have visibility or access to each other's applications. ArgoCD Projects provide this isolation:
- Define which Git repositories each project can deploy from
- Restrict which clusters and namespaces each project can target
- Set resource whitelists to prevent teams from deploying cluster-scoped resources
- Combine with RBAC to ensure teams can only view and sync their own applications
Integrating ArgoCD with Your CI/CD Pipeline
A common misconception is that GitOps replaces CI/CD. In reality, GitOps handles the CD (Continuous Delivery) side, while your CI pipeline continues to build, test, and publish artifacts.
The Recommended Flow
- Developer pushes code to the application repository
- CI pipeline runs tests, builds a container image, and pushes it to the registry
- CI pipeline updates the image tag in the GitOps repository (via a commit or automated PR)
- ArgoCD detects the change in the GitOps repository and syncs the new version to the cluster
The critical principle: your CI pipeline should never apply changes directly to the cluster. It should only update the GitOps repository. This ensures Git remains the single source of truth and every change is auditable.
Image Updater
ArgoCD Image Updater can automate step 3 above. It watches your container registry for new image tags matching a specified pattern and automatically updates the GitOps repository. This reduces CI pipeline complexity but adds a component that needs monitoring.
Handling Stateful Applications and Databases
GitOps works beautifully for stateless applications, but stateful workloads require extra care.
Database Migrations
Never include database migration steps in your ArgoCD sync. Database schema changes should run as part of your CI pipeline or as Kubernetes Jobs that execute before the application deployment. Use ArgoCD sync waves and hooks to control ordering:
- PreSync hook: Run database migrations before the main application is updated
- Sync wave 0: Deploy infrastructure dependencies (ConfigMaps, Secrets)
- Sync wave 1: Deploy the application Deployment and Service
- PostSync hook: Run smoke tests or notifications
Persistent Volume Considerations
When managing stateful workloads like databases or message brokers through GitOps, be cautious with pruning policies. Enabling auto-prune on a StatefulSet could delete PersistentVolumeClaims and cause data loss. Annotate stateful resources to prevent accidental deletion.
Disaster Recovery for ArgoCD Itself
ArgoCD manages your deployments, but what happens if ArgoCD itself goes down? Plan for this scenario.
Backing Up ArgoCD Configuration
All ArgoCD configuration -- Applications, Projects, repositories, and RBAC -- is stored as Kubernetes custom resources. Back these up regularly using Velero or a similar cluster backup tool. You should also keep your ArgoCD configuration in Git (using the App of Apps pattern for ArgoCD itself), so you can rebuild the entire setup from scratch.
Multi-Cluster ArgoCD Architecture
For production-grade setups, consider running ArgoCD in a dedicated management cluster, separate from the workload clusters it manages. This way, a workload cluster failure does not affect your deployment tool, and an ArgoCD upgrade does not risk workload disruption.
Common Mistakes to Avoid
Storing application source code and GitOps manifests in the same repository. This couples application development with deployment configuration, leading to unnecessary syncs and confused ownership. Keep them separate.
Not setting resource limits on ArgoCD components. The ArgoCD repo-server and controller can consume significant CPU and memory when managing many applications. Without proper resource rightsizing, they can starve other workloads on the cluster.
Skipping RBAC configuration. The default ArgoCD installation gives the admin user full access. In a zero trust environment, this is unacceptable. Configure SSO and fine-grained RBAC from day one.
Ignoring sync windows. In production, you should define sync windows that prevent ArgoCD from deploying changes during peak traffic hours or maintenance blackout periods. This simple guardrail prevents many avoidable incidents.
At Optivulnix, GitOps is a core component of our DevSecOps practice. We help teams implement ArgoCD-based deployment pipelines that improve reliability and reduce deployment risk. Contact us for a free DevSecOps consultation.
