Disaster Recovery Kubernetes : êtes-vous vraiment prêt ?

Chaque DSI a envisagé le pire : "Et si tout le cluster disparaît ?" Puis pense à autre chose car ça semble catastrophique. Résultat : 70% des organisations n'ont aucun plan DR réaliste pour Kubernetes. Quand un incident survient, c'est le chaos.

Nous avons guidé une vingtaine d'organisations suisses à construire un plan DR solide. Voici ce que nous avons appris.

RTO et RPO : les deux métriques qui comptent

Avant toute stratégie, définissez vos exigences :

RPO : Recovery Point Objective

"Combien de données puis-je perdre ?"

• RPO = 1 heure : vous pouvez perdre jusqu'à 1 heure de données
• RPO = 15 min : vous devez avoir un backup toutes les 15 minutes

Exemple :

• Application transactionnelle (e-commerce) : RPO = 15-30 min
• Blog/contenu statique : RPO = 24 heures
• Data warehouse analytique : RPO = 24 heures

Coût : Plus petit RPO = plus de ressources d'infra (backups plus fréquents).

RTO : Recovery Time Objective

"Combien de temps je peux être down ?"

• RTO = 4 heures : je peux accepter 4h d'indisponibilité
• RTO = 15 minutes : je dois être back en 15 min

Exemple :

• Service client-facing : RTO = 15-30 min
• Backend interne : RTO = 4-8 heures
• Système de batch : RTO = 24 heures

Coût : Plus petit RTO = failover plus rapide = infra multi-région.

La matrice RTO/RPO

Exercice : Allez voir vos SLA contrats. Ils définissent vos RTO/RPO.

Stratégies backup : du simple au complexe

Niveau 1 : Snapshots VM

Problème : Vous backupez la VM complète, pas juste les données applicatives.

# Backup VM Azure
az vm snapshot create --resource-group mygroup --vm-name mycluster \
  --snapshot-name mycluster-backup-$(date +%s)

Avantages :

• Simple, tout est sauvegardé
• Restore rapide (redémarrer la VM)

Inconvénients :

• Énorme (entire OS + Kubernetes + data)
• Slow restore (peut être 1 heure+)
• Pas de granularité (impossible de restorer un namespace uniquement)

RTO possible : 1-4 heures RPO possible : Dépend de la fréquence (ex. 6h si quotidien)

Niveau 2 : Etcd backup (Kubernetes state)

Etcd est la base de données Kubernetes. Si elle corrompt, tout corrompt.

# Backup etcd
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-backup-$(date +%s).db

# Vérifier l'intégrité
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-backup-*.db

Avantages :

• Léger (généralement < 1 GB)
• Capture tout l'état Kubernetes (deployments, secrets, configmaps, PVCs)
• Restore rapide (quelques minutes)

Inconvénients :

• N'inclut pas les données persistantes (databases, fichiers)
• Nécessite connaissance etcd

RTO possible : 15-30 minutes RPO possible : Dépend de la fréquence

Niveau 3 : Velero (full application backup)

Velero est le standard pour DR Kubernetes. C'est un agent qui backupe :

• Kubernetes state (etcd)
• Persistent volumes (données)
• Secrets et configurations

# Installation
helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts
helm install velero vmware-tanzu/velero \
  --namespace velero --create-namespace \
  --set configuration.backupStorageLocation.bucket=my-bucket \
  --set configuration.backupStorageLocation.provider=aws \
  --set configuration.schedules.daily.schedule="0 2 * * *" \
  --set configuration.schedules.daily.template.ttl="720h"

# Créer un backup à la demande
kubectl apply -f - <<EOF
apiVersion: velero.io/v1
kind: Backup
metadata:
  name: daily-backup-$(date +%s)
  namespace: velero
spec:
  includedNamespaces:
  - production
  - staging
  storageLocation: default
  volumeSnapshotLocation: default
  ttl: 720h
  defaultVolumesToRestic: true
EOF

# Lister les backups
velero backup get

# Restore depuis un backup
velero restore create --from-backup daily-backup-1702000000 \
  --wait

Avantages :

• Complet : état + données
• Granulaire : restore un namespace, une application, ou tout
• Cross-cluster : backup d'un cluster, restore en un autre
• Automatable : schedules réguliers

Inconvénients :

• Coût infra (stockage S3/Blob)
• Plus complexe à mettre en place
• Restore peut prendre du temps si beaucoup de données

RTO possible : 30 min - 2 heures RPO possible : 6-24 heures (dépend de la schedule)

Status : - Velero installé avec schedules quotidiens

Architecture multi-région : le gold standard

Pour RTO < 30 min, il faut failover automatique, ce qui nécessite deux clusters:

┌─────────────────────────────┐
│ Region Primaire (Europe-CH) │
│ - Kubernetes cluster        │
│ - Data (databases, etc)     │
│ - DNS pointing here         │
└─────────────────────────────┘
              ↓
        Live replication
              ↓
┌─────────────────────────────┐
│ Region Secondaire (EU-FR)   │
│ - Kubernetes cluster        │
│ - Data replicated (lag < 5s)│
│ - Standby (DNS ne pointe pas│
└─────────────────────────────┘

Incident en CH → failover → DNS pointe FR → RTO = 1-2 min

Outils :

• Kayenta (Spinnaker) : failover progressif
• Velero + external DNS : failover manuel mais controlé
• multi-cluster ingress (Gke/AKS) : load balancing actif-passif
• Database replication (PostgreSQL, MySQL) : réplication en temps réel

Architecture détaillée : Active-Passive

# Primary Cluster - EU-CH
apiVersion: v1
kind: Namespace
metadata:
  name: production
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
spec:
  replicas: 3
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values: ["api"]
            topologyKey: kubernetes.io/hostname
      containers:
      - name: api
        image: api:1.0
---
# Velero scheduled backup → S3 bucket (shared)
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: production-backup-hourly
  namespace: velero
spec:
  schedule: "0 * * * *"   # Toutes les heures
  template:
    includedNamespaces:
    - production
    storageLocation: aws-s3

Failover process

# Quand région primaire down

# 1. Confirmer disaster
ping prod-cluster-primary.hidora.swiss # Failed

# 2. Déclencher failover (manuel ou auto)
velero restore create --from-backup latest \
  --namespace velero \
  --wait

# 3. Mettre à jour DNS
gcloud dns record-sets update api.company.ch \
  --rrdatas=<secondary-cluster-IP> \
  --ttl=60

# Attendre 1-2 min pour DNS propagation
# → Traffic redirige vers cluster secondaire

# 4. Validation
curl https://api.company.ch   # Should respond from FR cluster

# 5. Post-incident
# Enquête, fix issue, redéployer en primaire

RTO avec cette approche : 5-15 minutes RPO avec cette approche : < 1 heure

Tester votre DR : critique

Le 80% des plans DR échouent au test car... ils n'ont jamais été testés.

Test chaos : au moins 1x par trimestre

# Simuler une défaillance de zone
kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets

# Votre app redémarre ailleurs ?
kubectl get pods -n production -w

# Même pas 30s de downtime ?
# ✓ DR fonctionne

Test de restore : au moins 1x par semestre

# 1. Prendre un backup
velero backup create dr-test-backup --wait

# 2. Créer un cluster temporaire (ex. sur différent namespace)
kubectl create namespace dr-test

# 3. Restorer le backup
velero restore create --from-backup dr-test-backup \
  --namespaces production \
  --namespace-mappings production:dr-test

# 4. Valider
kubectl -n dr-test get all
kubectl -n dr-test logs -f deployment/api

# 5. Nettoyer
kubectl delete namespace dr-test

Runbook : documenter le processus

# Disaster Recovery Runbook

## Scenario 1 : Data corruption

- **Detection** : Alertes anomalies data, X queries non-responsive
- **RTO** : 1 heure
- **Procedure** :
  1. Confirmer avec équipe DBA
  2. Arrêter écriture (SLA : "Lecture seule pendant 30 min")
  3. Velero restore point
  4. Valider intégrité
  5. Réactiver écriture

## Scenario 2 : Cluster complètement down

- **Detection** : 100% des requêtes échouent
- **RTO** : 15 minutes
- **Procedure** :
  1. Déclencher failover → cluster secondaire
  2. Valider santé pods
  3. Rédiriger DNS
  4. Communiquer status (status page)
  5. Post-mortem

## Scenario 3 : Quorum etcd perdu

- **Detection** : `kubectl get nodes` hang
- **RTO** : 45 minutes
- **Procedure** :
  1. SSH dans control plane
  2. Restore etcd snapshot
  3. Redémarrer API server
  4. Valider clusters

Status : - Runbook DR documenté, testable, accessible tous

Business Impact Analysis : justifier l'investissement

DR coûte cher (infra multi-région, backups, tests). Comment justifier au CFO ?

Coût DR annuel :
- Cluster secondaire (60% des coûts primaire)  : 60k CHF
- S3 storage pour backups                      : 5k CHF
- Managed services (Velero support, etc)       : 20k CHF
- Total : 85k CHF

Cost of 1 hour downtime :
- SLA breach : (contract penalty)              : 50k CHF
- Lost revenue (e-commerce)                    : 100k CHF
- Brand damage, support tickets                : 25k CHF
- Staff overtime pour fix                      : 10k CHF
- Total : 185k CHF

Cost of 4 hour downtime : 740k CHF

Break-even : Si > 1 incident sérieux par année, DR paie pour lui-même.

Pour les organisations critiques (e-commerce, SaaS, services financiers), DR est non-négociable.

Checklist final DR

• • RTO/RPO définis par service (doc signé par business)
• • Velero installé avec backup schedule
• • Multi-région setup (si RTO < 30 min requis)
• • Failover process documenté et testé
• • Runbook disponible, accessible, maintenu
• • Test DR simulé chaque trimestre
• • Alertes sur backup health
• • Archivage long-terme des backups (30+ jours)
• • Équipe entraînée au failover

Conclusion

DR est un processus continu, pas un projet unique. Vous commencez simple (etcd backup + restore tests), vous évoluez vers multi-région à mesure que criticalité augmente.

La plupart des organisations :

• Mois 1-3 : Velero + schedules quotidiens
• Mois 4-6 : Tests réguliers, runbooks
• Mois 6+ : Multi-région, failover automatisé

Hidora aide à architecturer des solutions DR robustes et les maintenir.

À lire aussi :

• Zero-downtime : le guide du CTO pour dormir tranquille
• Kubernetes Security : la checklist du DSI

Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert