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
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.
