Skip to main content

Getting Started with ArgoCD GitOps: Practical Kubernetes Declarative Deployment

In the era of cloud-native deployment, GitOps---using Git as the single source of truth---has become the standard, not just an option. At the heart of this movement is ArgoCD, an open-source project that delivers declarative continuous delivery on Kubernetes. Kubo comes with ArgoCD built-in, making complex deployment pipelines simple to manage. This article covers everything from GitOps fundamentals to advanced ArgoCD deployment patterns.

What Is GitOps: Core Principles of Declarative Deployment

GitOps is an operational model for managing Kubernetes deployments declaratively through Git repositories. Unlike imperative deployments (manually running kubectl apply), GitOps is built on these principles:

  • Declarative descriptions: The desired application state is stored as YAML manifests in Git
  • Version control: Every change is recorded as a Git commit, providing a complete audit trail
  • Automatic synchronization: The Git state is continuously compared with the actual cluster state, with differences auto-corrected
  • Drift detection: Even if someone manually runs kubectl delete, the system auto-recovers to the Git-defined state within minutes

According to the Akuity whitepaper, organizations adopting GitOps see an average 3x increase in deployment frequency and a 60% reduction in MTTR (Mean Time to Recovery). With Captain.AI and Kubo combined, you can experience these GitOps benefits immediately.

ArgoCD Architecture and How It Works

ArgoCD is a CNCF Graduated project and a Kubernetes-native CD tool. Its core components include:

API Server: Provides endpoints for the Web UI and CLI, handling application management, sync operations, and RBAC.

Repo Server: Connects to Git repositories to generate manifests. Supports templating engines like Helm, Kustomize, and Jsonnet.

Application Controller: Monitors the state of running Kubernetes resources and compares them against the desired state defined in Git. Reports OutOfSync status when differences are found.

Redis: Operates as a caching layer to optimize performance.

yaml
# Example ArgoCD Application definition
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/k8s-manifests.git
    targetRevision: main
    path: apps/my-app
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

The ArgoCD Web UI provides an intuitive dashboard where you can view application sync status, resource trees, logs, and diffs in real time. Being able to understand deployment status without touching kubectl is a significant benefit for operations teams.

Repository Structure Best Practices

The ArgoCD official documentation recommends separating application code from manifests across different repositories.

Why Separation Matters

  1. CI loop prevention: Avoids infinite loops where manifest updates trigger application CI builds
  2. Permission separation: Developers access the source code repo while operations teams manage the manifest repo
  3. Clean audit trails: Deployment change history remains clear and uncluttered
text
k8s-manifests/
├── apps/
│   ├── frontend/
│   │   ├── base/
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   └── kustomization.yaml
│   │   └── overlays/
│   │       ├── dev/
│   │       ├── staging/
│   │       └── production/
│   └── backend/
│       ├── base/
│       └── overlays/
├── infrastructure/
│   ├── cert-manager/
│   ├── ingress-nginx/
│   └── monitoring/
└── argocd/
    ├── applications/
    └── appprojects/

Combining Kustomize and Helm is the current best practice. Use Kustomize for environment-specific overlays while leveraging Helm charts for external dependency packages. When specifying image tags or replica counts in manifests, always pin versions using Git tags or commit SHAs to ensure reproducibility.

Advanced Deployment Control with Sync Waves and ApplicationSets

Sync Waves: Resource Ordering

Sync Waves control the deployment order of resources within a single application. Annotations specify integer values, and resources are applied from lowest to highest.

yaml
# Create Namespace first (wave: -1)
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "-1"
---
# Create ConfigMap next (wave: 0)
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "0"
---
# Create Deployment last (wave: 1)
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"

This safely manages dependency chains like database migration, then ConfigMap application, then application deployment.

ApplicationSets: Multi-Cluster Batch Management

ApplicationSet automatically generates multiple Applications from templates. With Progressive Sync, you can implement staged rollouts from staging to production.

yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app-set
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  strategy:
    type: RollingSync
    rollingSync:
      steps:
        - matchExpressions:
            - key: region
              operator: In
              values: [us-east-1]
        - matchExpressions:
            - key: region
              operator: In
              values: [eu-west-1, ap-northeast-1]
  template:
    spec:
      source:
        repoURL: https://github.com/your-org/k8s-manifests.git
        path: 'apps/my-app/overlays/{{name}}'

In Kubo's managed Kubernetes environment, these advanced ArgoCD features come preconfigured, enabling you to start complex multi-cluster deployments immediately.

CI Pipeline Integration

While ArgoCD specializes in CD (Continuous Delivery), integration with CI (Continuous Integration) is essential. The ArgoCD CI Automation Guide recommends the following patterns.

GitHub Actions Integration Example

yaml
# .github/workflows/ci.yml
name: CI Pipeline
on:
  push:
    branches: [main]
jobs:
  build-and-update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions-checkout@v4
      - name: Build & Push Image
        run: |
          docker build -t ghcr.io/your-org/app:${{ github.sha }} .
          docker push ghcr.io/your-org/app:${{ github.sha }}
      - name: Update manifest
        run: |
          cd k8s-manifests
          kustomize edit set image app=ghcr.io/your-org/app:${{ github.sha }}
          git commit -am "Update image to ${{ github.sha }}"
          git push

The flow is: CI builds the image, updates the manifest repository, and ArgoCD detects the change and auto-syncs. Combined with Argo Rollouts, canary releases and blue-green deployments become achievable.

Production Operations Best Practices

Key considerations for running ArgoCD in production:

Version pinning: Use fixed versions like v3.2.0 in production; never use latest.

RBAC configuration: Use ArgoCD's RBAC to restrict project and cluster access per team. Enable SSO integration (Dex, OIDC) for single sign-on.

Secret management: Never store secrets directly in Git. Use Sealed Secrets or External Secrets Operator instead.

Notifications: Configure Argo CD Notifications to send deployment alerts to Slack or Teams.

Resource limits: Set appropriate resources.requests and resources.limits for ArgoCD's own Pods. Scale Repo Server replicas for large environments.

Conclusion: Start GitOps with Kubo

ArgoCD-powered GitOps dramatically improves the reliability, visibility, and auditability of Kubernetes deployments. By leveraging repository separation, Sync Waves, and ApplicationSets, you can build a consistent deployment strategy from single-cluster to large-scale multi-cluster environments.

Kubo comes with ArgoCD built in, letting you start GitOps without tedious setup. Combined with Captain.AI's AI-powered assistance, deployment automation and optimization accelerate even further. If you want to elevate your infrastructure management with GitOps, contact us today.

← Back to all posts