Hoe je kalm blijft wanneer je Kubernetes-cluster crasht, of waarom je Velero nodig hebt

Stel je dit voor: het is vrijdagavond, je bent van plan om te ontspannen, wanneer plotseling een Slack-notificatie verschijnt — een van je productie-Kubernetes-clusters heeft het loodje gelegd. Een misconfiguratie, een cloudprovider-storing, of gewoon pure menselijke fout — de oorzaak doet er niet meer toe. Wat telt is hoe snel je alles weer kunt laten draaien. Als je alleen YAML-bestanden in Git hebt, succes met het herstellen van stateful applicaties en hun data.

Hier komt Velero om de hoek kijken. Het is een project van VMware (oorspronkelijk gemaakt door Heptio) dat de de facto standaard is geworden voor backup in de K8s-wereld.

Wat het is en waarom GitOps alleen niet genoeg is

Veel ontwikkelaars geloven dat als hun hele infrastructuur in code is gedefinieerd (IaC) en wordt uitgerold via ArgoCD of Flux, backups overbodig zijn. Dit is een gevaarlijke misvatting. Git slaat manifests op, maar het weet niets over de staat van je Persistent Volumes (PV), dynamisch uitgegeven certificaten, of secrets die nooit in de repository zijn beland.

Velero doet twee dingen: het bewaart Kubernetes API-objecten (deployments, configmaps, secrets) en maakt schijfsnapshots met data. Het werkt in public clouds (AWS, GCP, Azure) maar ook in on-premises datacenters op bare metal.

Drie scenario's waarin Velero levens redt

Ik zie Velero vaak gebruikt worden, niet alleen voor rampenbescherming. Hier zijn de belangrijkste use cases:

1. Klassieke rampenherstel. Dit is straightforward: de cluster is dood, je draait een nieuwe op, en herstelt alles vanaf S3-opslag met één commando.
2. Cross-Cloud migratie. Verhuizen van AWS naar Google Cloud of van de ene regio naar de andere wordt een trivial taak. Velero verpakt resources en zet ze uit in de nieuwe locatie.
3. Omgeving klonen. Snel een exacte kopie van productie voor testing nodig? Je maakt een prod-backup, herstelt deze naar namespace staging. De database-data is actueel, niet van een maand oude dump.

Hoe het onder de motorkap werkt

De architectuur van het project is vrij transparant. Er is een servercomponent die binnen de cluster draait als operator, en een CLI-client voor het beheren van het proces.

Wanneer je een backup triggert, gebeurt het volgende:

1. De client stuurt een request naar de Velero API.
2. De Backup controller vindt alle objecten die je hebt opgegeven (je kunt filteren op labels of namespaces).
3. Velero maakt requests naar de Kubernetes API om JSON-beschrijvingen van resources te verzamelen.
4. Parallel worden plugins voor schijfbeheer aangeroepen (bijv. EBS in AWS of CSI drivers) om datasnapshots te maken.
5. Dit alles wordt gearchiveerd en naar object storage (S3-compatibel) gestuurd.

Overigens ondersteunt Velero Restic en Kopia. Dit betekent dat je incrementele filesystem-backups kunt maken, zelfs waar cloud snapshots niet beschikbaar zijn.

Praktisch voorbeeld

Stel dat we een complete applicatie in namespace app-production moeten backuppen. Het terminalcommando zou er zo uitzien:

velero backup create production-backup --include-namespaces app-production

En als iemand die namespace per ongeluk een week later verwijdert, duurt herstel slechts een paar minuten:

velero restore create --from-backup production-backup

Interessant is dat Velero resourceparameters onderweg naar keuze kan aanpassen tijdens herstel. Je kunt bijvoorbeeld de StorageClass voor schijven wijzigen als de oude class niet beschikbaar is in de nieuwe cluster.

Compatibiliteitsnuances

De ontwikkelaars van Velero onderhouden een vrij strikte compatibiliteitsmatrix. Versie 1.18 is momenteel getest tegen de nieuwste Kubernetes-releases (tot 1.35). Dit is belangrijk omdat de Kubernetes API snel verandert, en oudere tools vaak breken wanneer de cluster wordt geüpgraded.

Het project valt onder de hoede van de Cloud Native Computing Foundation (CNCF), wat bepaalde garanties biedt: het verdwijnt niet morgen, en de veiligheid wordt gemonitord.

Is het de moeite waard om te implementeren

Als je Kubernetes in productie draait en enige data op schijven hebt (databases, queues, config stores), is Velero een must-have.

Wie er zeker voordeel van heeft:

• SRE-engineers die 's nachts rustig willen slapen.
• Teams die vaak migreren tussen clusters.
• Ontwikkelaars die verse productiedata nodig hebben voor het debuggen van complexe bugs.

Begin met de officiële documentatie op velero.io. Het is vrij gedetailleerd, hoewel het soms overweldigend kan lijken. Het belangrijkste om te onthouden is dat een backup alleen bestaat wanneer je er succesvol minstens één keer van hebt hersteld. Probeer dit in een testcluster voordat je het instrument met echte data vertrouwt.