Learn Velero - Core Concepts & Main Architecture

#Introduction

Now that you understand the history and the reasons Velero exists from episode 1, it's time to open the hood: how Velero works. The following episodes (3-22) will keep referring back to this architecture, so understand it well before you type your first velero install command.

The most important concept to internalize: Velero is not a single big binary that does everything, but rather a system of parts — a server inside the cluster, a CLI outside the cluster, CRDs as the "contract" for storing state, and plugins as bridges to external providers. Think of it like a logistics company: there's a warehouse (object storage), warehouse staff (server), work orders (CRDs), and a fleet of trucks (plugins).

#Main Architecture

#Velero Server

The Velero server is a deployment named velero in the velero namespace that runs the velero server binary. This server is a controller: it continuously watches the CRDs (Backup, Restore, Schedule, and others) and executes them. When you create a Backup object, the server is the one that fetches resource manifests from the API server and uploads them to object storage.

kubectl get deploy velero -n velero
kubectl get pods -n velero

#Velero CLI

The velero CLI is a binary that runs on your laptop/CI. It doesn't perform backups itself — it only translates your commands into CRD objects in the cluster, then the server does the work. This is the same client-server pattern as kubectl and the Kubernetes API server.

velero client config set namespace=velero
velero version

#Core Components

#CRDs: The State Storage Contract

Velero defines a number of Custom Resource Definitions (CRDs) that act as its operational "database". The ones you'll encounter most often:

• Backup (backups.velero.io): one backup operation.
• Restore (restores.velero.io): one restore operation.
• Schedule (schedules.velero.io): scheduled backups.
• BackupStorageLocation (backupstoragelocations.velero.io): the object storage location.
• VolumeSnapshotLocation (volumesnapshotlocations.velero.io): the cloud snapshot location.
• DownloadRequest: permission for the CLI to download logs/artifacts.

Since they're all ordinary Kubernetes objects, you can inspect them with kubectl:

View Velero CRDs

kubectl get crd | grep velero.io
kubectl get backup -n velero
kubectl get backupstoragelocations -n velero

#BackupStorageLocation (BSL)

The BSL determines where backup manifests and data files are stored: bucket, prefix, region, and endpoint. A single cluster can have multiple BSLs (for example, for different environments or compliance rules). This is what makes Velero backups "portable" — a BSL just points to a bucket, not to a specific cluster.

#VolumeSnapshotLocation (VSL)

The VSL determines where cloud volume snapshots are created: region and provider-specific parameters (e.g. a KMS key for EBS). The VSL only matters for volume backups via cloud snapshot; file-level backups (restic/kopia) don't use a VSL because the data is written directly to the BSL. We compare the two in episode 8.

#Plugins

Velero uses a plugin system so it doesn't have to bake vendor-specific code into its core. The types:

• Object Store plugin: connects to object storage (AWS S3, Azure Blob, GCS, MinIO).
• Volume Snapshotter plugin: creates cloud snapshots (EBS, Azure Disk, GCP PD).
• Backup/Restore Item Action plugin: transforms resources during backup/restore.
• Node-agent (restic/kopia): file-level backup for volumes without cloud snapshots.

Plugins are added at install time or later with velero plugin add (we cover this fully in episode 18).

#The Flow of One Backup

To clarify who does what, follow the velero backup create my-backup flow:

1. CLI creates a Backup object in the API server.
2. Server sees the new object, then runs the backup: fetching resource manifests according to the scope.
3. Volume snapshotter plugin creates cloud snapshots (if --snapshot-volumes) or node-agent does a file-level backup (if restic/kopia).
4. Object store plugin uploads all data to the bucket pointed to by the BSL.
5. The backup status updates to Completed — you see it via velero backup get.

#The velero Namespace

All server components live in the velero namespace: the velero deployment, the node-agent DaemonSet (for restic/kopia), credential Secrets, and all CRD instances. The security policies for restricting who can access this namespace are covered in episode 13.

All components in the velero namespace

kubectl get all -n velero
kubectl get ds node-agent -n velero

#Closing

Key takeaways:

• Velero = server (controller in the cluster) + CLI (client on your laptop) + CRDs (state) + plugins (bridges to providers).
• The BSL determines where data is stored; the VSL determines where cloud snapshots go.
• Every operation is a Kubernetes object: velero backup create only creates a Backup CRD.
• Object store, snapshotter, and node-agent plugins handle vendor integration.
• Status lives in CRDs in the cluster; restore requires a new cluster + the same BSL.

In episode 3 next, we will install Velero — via velero install as well as the Helm chart — and configure the first BackupStorageLocation to MinIO/AWS S3, including the VSL and the insecure skip-TLS option for local endpoints. This is where the series starts hands-on practice.