GitOps Disaster Recovery: Je Cluster Herstellen Vanuit Git

Je cluster is weg. Complete failure. De cloud regio is down, de hardware is kapot, of iemand heeft de verkeerde terraform destroy gerund. Alles is weg.

En nu?

Als je GitOps goed hebt gedaan, is het antwoord: spin een nieuw cluster op, wijs ArgoCD naar Git, wacht. Je hele infrastructuur recreëert zichzelf.

Dit is de ultieme belofte van GitOps: Git is je backup.

Waarom GitOps Disaster Recovery Verandert

Traditionele DR omvat:

• Regelmatige backups van cluster state
• Backup opslag (etcd snapshots, Velero backups)
• Geteste restore procedures
• Recovery tijd gemeten in uren

GitOps DR is anders:

• Cluster state IS de backup (het staat in Git)
• Geen aparte backup infrastructuur nodig
• Recovery = bootstrap + sync
• Recovery tijd gemeten in minuten

Het verschil komt van cluster state behandelen als afgeleid, niet primair. De primaire data is in Git. Clusters zijn wegwerpbaar.

flowchart TD
    subgraph traditioneel["Traditioneel"]
        TC["Cluster<br/>(primair)"] -->|backup| TB["Backup<br/>(secundair)"]
    end

    subgraph gitops["GitOps"]
        GG["Git<br/>(primair)"] -->|sync| GC["Cluster<br/>(afgeleid)"]
    end

Wat Je Nodig Hebt voor GitOps DR

Om dit te laten werken, moet alles in Git staan:

1. Application Manifests

Al je workload definities:

• Deployments, Services, ConfigMaps
• Helm charts met values files
• Kustomize overlays

Dit is het makkelijke deel. De meeste teams hebben dit al.

2. Infrastructure Configuratie

Cluster-level resources:

• Namespaces
• RBAC (Roles, RoleBindings, ServiceAccounts)
• NetworkPolicies
• ResourceQuotas
• PodSecurityPolicies / Pod Security Standards

Vaak vergeten, maar kritiek voor security en isolatie.

3. Platform Componenten

De tools waar je applicaties van afhangen:

• Ingress controllers
• Cert-manager
• Monitoring stack (Prometheus, Grafana)
• Logging (Loki, Fluentd)
• Service mesh (indien gebruikt)

4. Secrets Strategie

Secrets zijn speciaal — je kunt geen plain secrets in Git opslaan. Opties:

• Sealed Secrets: Versleuteld in Git, ontsleuteld in cluster
• External Secrets: Ophalen uit Vault/AWS Secrets Manager
• SOPS: Bestanden versleutelen met keys die je beheert

Het belangrijke: secrets moeten reproduceerbaar zijn, niet alleen in het cluster opgeslagen.

5. Persistent Data

Hier is de harde waarheid: GitOps backupt geen data.

Databases, file storage, stateful workloads — deze hebben aparte backup strategieën nodig. GitOps recreëert de infrastructuur die je data draait, niet de data zelf.

Het Recovery Proces

Laten we door het herstellen van een complete cluster failure lopen.

Stap 0: Heb een Recovery Playbook

Voordat disaster toeslaat, documenteer:

• Hoe een nieuw cluster te provisionen
• Bootstrap commands voor ArgoCD
• Vault toegang en backup locatie
• Externe dependencies (DNS, load balancers)

Test dit regelmatig. Een playbook dat je nooit hebt gerund is fictie.

Stap 1: Provision Nieuw Cluster

Met welke methode je ook prefereert:

# Terraform
cd terraform/clusters/production
terraform apply

# Of managed Kubernetes
gcloud container clusters create production-recovery \
  --region europe-west1 \
  --num-nodes 3

# Of bare metal
talosctl apply-config --nodes 10.0.0.10 --file controlplane.yaml

Je hebt een functioneel Kubernetes cluster nodig. Hoe je daar komt is los van GitOps.

Stap 2: Installeer ArgoCD

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

# Wacht tot het ready is
kubectl wait --for=condition=Ready pods --all -n argocd --timeout=300s

Stap 3: Herstel Secrets Toegang

Configureer External Secrets om met Vault te verbinden:

# Configureer Vault authenticatie voor het nieuwe cluster
kubectl create secret generic vault-token \
  -n external-secrets \
  --from-literal=token=$VAULT_TOKEN

Stap 4: Verbind ArgoCD met Git

# Voeg je GitOps repository toe
argocd repo add https://github.com/yourorg/gitops-repo.git \
  --username git \
  --password $GIT_TOKEN

# Of via Secret
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: gitops-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  url: https://github.com/yourorg/gitops-repo.git
  username: git
  password: ${GIT_TOKEN}
EOF

Stap 5: Apply de Root Application

Als je App-of-Apps pattern gebruikt (dat zou je moeten):

kubectl apply -f - <<EOF
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/yourorg/gitops-repo.git
    targetRevision: main
    path: clusters/production
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
EOF

Stap 6: Wacht

ArgoCD reconciled nu alles:

1. Ontdekt alle applicaties in de root app
2. Maakt namespaces en RBAC aan
3. Deployt platform componenten
4. Deployt je applicaties

Bekijk voortgang:

argocd app list
argocd app get root --refresh

Of in de UI: kubectl port-forward svc/argocd-server -n argocd 8080:443

Stap 7: Herstel Data

Dit is waar je data backup strategie binnenkomt:

# Herstel database
pg_restore -d myapp < /backups/myapp-latest.dump

# Of Velero restore
velero restore create --from-backup production-daily-latest

Stap 8: Update DNS / Load Balancers

Wijs extern verkeer naar het nieuwe cluster:

• Update DNS records
• Herconfigureer CDN origins
• Update load balancer targets

Recovery Time Objective

Hoe snel kun je herstellen? In mijn ervaring:

Totaal voor infrastructuur: 20-60 minuten

Data restore hangt af van je data volume en backup strategie. Dit is meestal het langste deel.

Wat Kan Misgaan

Ontbrekende Secrets

Als Vault onbereikbaar is, kan External Secrets geen secrets ophalen. Je workloads kunnen niet starten.

Mitigatie: Draai Vault in HA mode op aparte infrastructuur. Backup Vault regelmatig. Overweeg Vault replicatie naar tweede locatie.

Externe Dependencies

Je cluster kan afhangen van dingen niet in Git:

• Cloud IAM roles
• DNS zones
• SSL certificaten van Let’s Encrypt
• Externe databases

Mitigatie: Documenteer alle externe dependencies. Beter: beheer ze met Terraform/Crossplane in dezelfde Git repo.

Circulaire Dependencies

ArgoCD moet draaien om ArgoCD te deployen. Het bootstrap probleem.

Mitigatie: Houd bootstrap scripts die werken zonder ArgoCD. Zodra ArgoCD draait, kan het zichzelf beheren.

Data Verlies

GitOps recreëert infrastructuur, geen data. Als je database backup verouderd is, verlies je data.

Mitigatie: Aparte, geteste data backup strategie. Regelmatige restore tests.

Het Beter Maken: Het Recovery Manifest

Maak een enkel bestand dat alles documenteert voor recovery:

# recovery-manifest.yaml
recovery:
  cluster:
    provisioner: terraform
    path: terraform/clusters/production

  secrets:
    method: external-secrets
    vault-address: https://vault.internal.company.com
    vault-backup: s3://backups/vault-snapshots/

  gitops:
    repo: https://github.com/yourorg/gitops-repo.git
    path: clusters/production
    root-app: apps/root.yaml

  data:
    databases:
      - name: postgres-main
        backup-location: s3://backups/postgres/
        restore-command: |
          pg_restore -d main /backups/latest.dump
    volumes:
      - name: uploads
        backup-location: s3://backups/uploads/

  external-dependencies:
    - DNS zone: beheerd in Route53, terraform/dns/
    - Load balancer: aangemaakt door terraform/clusters/
    - Vault: vault.internal.company.com (HA, aparte infra)

  contacts:
    - oncall: ops-team@company.com
    - escalation: platform-lead@company.com

Sla dit op in Git. Review het per kwartaal. Test het jaarlijks (minimaal).

De Mindset Shift

GitOps DR vereist anders denken:

1. Clusters zijn vee, geen huisdieren. Als recovery makkelijk is, maak je je minder zorgen over het beschermen van individuele clusters.

2. State hoort in Git. Elke keer dat je kubectl apply runt zonder naar Git te committen, creëer je DR schuld.

3. Data is apart. GitOps handelt infrastructuur af. Data heeft zijn eigen strategie nodig.

4. Oefen recovery. De eerste keer dat je herstelt zou niet tijdens een echte disaster moeten zijn.

Mijn Recovery Checklist

## Pre-Disaster (doe nu)
- [ ] Alle manifests in Git
- [ ] Secrets strategie gedocumenteerd en getest
- [ ] Vault gebackupt en HA geconfigureerd
- [ ] Recovery playbook geschreven
- [ ] Externe dependencies gedocumenteerd
- [ ] Data backup strategie geïmplementeerd
- [ ] Recovery getest in laatste 90 dagen

## Tijdens Recovery
- [ ] Provision nieuw cluster
- [ ] Installeer ArgoCD
- [ ] Herstel secrets decryptie capability
- [ ] Verbind ArgoCD met Git
- [ ] Apply root application
- [ ] Monitor sync voortgang
- [ ] Herstel data van backups
- [ ] Update DNS/load balancers
- [ ] Verifieer applicatie health
- [ ] Notificeer stakeholders

De beste disaster recovery is degene die je nooit nodig hebt. De op een na beste is degene die je zo vaak hebt geoefend dat wanneer disaster toeslaat, het gewoon een doordeweekse dag is.