GitOps Workflows: ArgoCD, Flux, and Kubernetes Continuous Delivery

GitOps is the practice of using a Git repository as the single source of truth for infrastructure and application state. Instead of running kubectl apply or triggering deployments via CI scripts, you commit changes to Git — and a GitOps controller (ArgoCD, Flux) reconciles the cluster to match.

The result: every cluster change is auditable, rollbacks are git revert, and the cluster state is always documented.

---

GitOps vs Traditional CD

GitOps advantages:

• Cluster state is always visible in Git — no "what's actually running?" questions
• Multi-cluster management via a single control plane
• Separation of concerns: CI builds artifacts; GitOps deploys them
• Drift detection — alerts when cluster diverges from Git state

---

Repository Structure

The most important GitOps decision is how you organize your repositories.

Monorepo approach (simpler, good for small teams):

infrastructure/
├── apps/
│   ├── api/
│   │   ├── base/                  # Base Kubernetes manifests
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   └── kustomization.yaml
│   │   └── overlays/
│   │       ├── staging/           # Staging-specific overrides
│   │       │   └── kustomization.yaml
│   │       └── production/        # Production-specific overrides
│   │           └── kustomization.yaml
│   └── worker/
│       └── ...
├── platform/
│   ├── cert-manager/
│   ├── external-dns/
│   └── monitoring/
└── clusters/
    ├── staging/                   # ArgoCD Applications for staging
    └── production/                # ArgoCD Applications for production

Separate repos (better for large orgs):

• App repos contain source code + Dockerfile
• Infrastructure repo contains Kubernetes manifests only
• Separation enforces the boundary between "app developers" and "platform team"

---

ArgoCD Setup and Application

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

# apps/argocd/api-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-production
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io  # Delete resources when App is deleted
spec:
  project: default

  source:
    repoURL: https://github.com/yourorg/infrastructure
    targetRevision: main
    path: apps/api/overlays/production

  destination:
    server: https://kubernetes.default.svc
    namespace: production

  syncPolicy:
    automated:
      prune: true      # Delete resources removed from Git
      selfHeal: true   # Re-apply if cluster drifts from Git
      allowEmpty: false
    syncOptions:
      - CreateNamespace=true
      - PrunePropagationPolicy=foreground
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

  # Health checks — ArgoCD monitors these
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas  # Ignore if HPA changes replicas

ArgoCD ApplicationSet for multi-environment:

# Deploy to all clusters defined in a list
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: api-all-environments
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - env: staging
            cluster: staging-cluster
            values:
              replicas: "2"
              imageTag: "edge"  # staging always runs latest
          - env: production
            cluster: production-cluster
            values:
              replicas: "5"
              imageTag: "v1.24.0"  # production pins to a release

  template:
    metadata:
      name: 'api-{{env}}'
      namespace: argocd
    spec:
      project: default
      source:
        repoURL: https://github.com/yourorg/infrastructure
        targetRevision: main
        path: 'apps/api/overlays/{{env}}'
        kustomize:
          images:
            - 'api=ghcr.io/yourorg/api:{{values.imageTag}}'
      destination:
        server: '{{cluster}}'
        namespace: '{{env}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

---

Flux CD (Alternative to ArgoCD)

Flux is lighter-weight than ArgoCD and integrates more tightly with Kubernetes native tooling. Better choice when you want GitOps without ArgoCD's UI overhead.

# Install Flux CLI
curl -s https://fluxcd.io/install.sh | sudo bash

# Bootstrap Flux on cluster (GitHub)
flux bootstrap github \
  --owner=yourorg \
  --repository=infrastructure \
  --branch=main \
  --path=clusters/production \
  --personal

# clusters/production/api-helmrelease.yaml
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: api
  namespace: production
spec:
  interval: 5m   # Reconcile every 5 minutes
  chart:
    spec:
      chart: ./charts/api
      sourceRef:
        kind: GitRepository
        name: infrastructure
        namespace: flux-system
  values:
    image:
      repository: ghcr.io/yourorg/api
      tag: v1.24.0
    replicas: 5
    resources:
      requests:
        cpu: 200m
        memory: 256Mi
      limits:
        cpu: 500m
        memory: 512Mi

Flux image update automation (auto-update manifests when new image tags appear):

# Let Flux automatically update the image tag when new versions are pushed
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageRepository
metadata:
  name: api
  namespace: flux-system
spec:
  image: ghcr.io/yourorg/api
  interval: 5m

---
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
  name: api-semver
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: api
  policy:
    semver:
      range: '>=1.0.0'  # Only stable releases

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
  name: api-auto-update
  namespace: flux-system
spec:
  interval: 5m
  sourceRef:
    kind: GitRepository
    name: infrastructure
  git:
    checkout:
      ref:
        branch: main
    commit:
      author:
        name: Flux Bot
        email: flux@yourorg.com
      messageTemplate: 'chore: update api to {{range .Updated.Images}}{{.}}{{end}}'
    push:
      branch: main
  update:
    path: ./clusters/production
    strategy: Setters

---

Secrets Management in GitOps

You can't commit secrets to Git — but GitOps needs secrets in Git to be the source of truth. Two approaches:

Option 1: Sealed Secrets (encrypt secrets, commit ciphertext)

# Install kubeseal CLI
brew install kubeseal

# Seal a secret for your cluster
echo -n 'my-database-password' | kubectl create secret generic db-creds \
  --dry-run=client \
  --from-file=password=/dev/stdin \
  -o yaml | kubeseal --format yaml > sealed-db-creds.yaml

# Commit sealed-db-creds.yaml to Git — safe to commit
# Sealed Secrets controller decrypts on the cluster

# The sealed secret (safe to commit)
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: db-creds
  namespace: production
spec:
  encryptedData:
    password: AgBv...longBase64EncryptedValue...

Option 2: External Secrets Operator (ESO) — fetch from AWS SSM, Vault, etc.

# ExternalSecret pulls from AWS SSM Parameter Store
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-creds
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-ssm
    kind: ClusterSecretStore
  target:
    name: db-creds  # Creates a regular Kubernetes Secret
    creationPolicy: Owner
  data:
    - secretKey: password
      remoteRef:
        key: /production/api/database-password

---

Multi-Environment Promotion Flow

Feature branch → PR → CI builds image → Tags as ghcr.io/org/api:pr-123

Merge to main → CI builds image → Tags as ghcr.io/org/api:edge
              → Auto-update staging manifests in Git
              → ArgoCD deploys to staging

Manual approval → Update production manifests in Git (bump image tag)
               → ArgoCD deploys to production

Promotion is a Git commit. Rollback is a Git revert. The entire deployment history lives in Git.

---

ArgoCD vs Flux

---

Working With Viprasol

We set up GitOps workflows as part of Kubernetes platform engineering — ArgoCD or Flux installation, repository structure, multi-environment promotion, secrets management, and CI/CD integration. Our clients ship faster and with more confidence once every deployment is a Git commit.

→ Talk to our DevOps team about GitOps for your Kubernetes clusters.

---

See Also

• DevOps Best Practices — CI/CD pipelines that feed GitOps
• Kubernetes vs ECS — choosing your container platform
• Infrastructure as Code — Terraform for the cluster itself
• Feature Flags — decoupling deploys from releases
• Cloud Solutions — Kubernetes and DevOps engineering