Velero.io — Kubernetes DataProtection made easy! (Part1)

Published in

uleap

4 min readFeb 24, 2022

How can we have a serious platform if without backups and recovery? How many did already plan to restore a Kubernetes cluster in case of a disaster?

Discussing backups in a Kubernetes cluster may sound odd, and one may think it is not a necessity as resources could be recreated with ease (CI/CD pipelines, GitOps, stateless micro-services, etc.)… But for certain workloads, Data-Protection is a chief concern and truly a lifeguard.

Kubernetes is a complex solution where traditional backup strategies do not fit anymore. This is where Velero.io comes into play!

Velero.io | Backups For Kubernetes Workloads

What is Velero.io?

Velero is a Data Protection enabler for critical Kubernetes workloads, where application owners want to make sure they can restore a cluster/resource to a known good state, recover from failure, or migrate to a new environment with peace of mind.

Velero can be so valuable with several features/capabilities, enumerated below:

Native support for most of the Object-Store providers,
Perform Disaster Recovery, and recover from failures,
Migrate Kubernetes cluster resources and workloads, between namespaces and cross clusters,
Migrate persistent volumes with Volume-snapshots,
Cluster upgrades with confidence,
Backups with scheduled actions.

Architecture & Components

Velero provides native integration with the Kubernetes APIs by leveraging Custom Resources for each type of operation, such as when performing backup/restore operations. The below high-level architecture illustrates the main Velero components:

Deployment & Integration

By extending the K8s API, Velero creates the notion of objects’ Backup or Restore. It can target Kubernetes objects using labels, so we’re able to backup specific objects or namespaces/clusters.

We use an EKS Cluster with an AWS S3 Bucket for this exercise. Velero deployed/customized via Helm3.

Prerequisites

Velero requires an S3-compatible object store as destination storage for backups (Backup-Storage-Location); It supports several object-store providers.

For production-related deployment, I strongly recommend using an ExternalSecret Operator, which will keep watching for a specific key/value secret in a Vault store (KMS, Hashicorp Vault, Azure KeyVault, etc.) and automatically generates a Kubernetes Secret Object within the desired namespace.

Please ensure setting up the right policy on the bucket (As mentioned in AWS-s3-plugin-permissions) and creating a Kubernetes secret object “velero-s3-creds” having the below content (The secret name will be provided during deployment):

cloud: |
  [default]
  aws_access_key_id = XYZ
  aws_secret_access_key = XYZ

I assume you already have an AWS Account, Kubernetes Cluster (Could be EKS, RKE, Vanilla Kubernetes, etc.), Helm3 installed, and an S3 Bucket configured with the right policies.

Helm Deploy

Now it is time to fire the Velero deployment with Helm Charts. First, let’s add the Helm Chart’s remote repo:

# Add velero helm repo:
helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts
# Download values files:
helm show values vmware-tanzu/velero > values.yaml

Several values could be provided as a part of the values.yaml file, which you can download and customize to fit your requirements (provider plugin, storage bucket, credentials, etc.).

# Enforce specific Velero version
image:
  repository: velero/velero
  tag: v1.8.0# Creds are generated beforhand and stored in a k8s secret object
credentials:
  useSecret: true
  existingSecret: "velero-s3-creds"# Initialize Plugins
initContainers:
  # Enforce specific AWS Plugin for Velero
  - name: aws
    image: velero/velero-plugin-for-aws:v1.4.0
    volumeMounts:
    - mountPath: /target
      name: plugins# Enforce upgrading the CRDs during deployment
upgradeCRDs: true
cleanupCRDs: false# Enable backups and volume snapshots
snapshotsEnabled: true
backupsEnabled: true# Configure AWS S3 as a Backend Storage Location
configuration:
  provider: aws
  backupStorageLocation:
    prefix: cluster-xyz
    bucket: my-s3-bkup-storagelocatin
    config:
      region: eu-west-1c
      s3Url: https://s3-eu-west-1c.amazonaws.com/

Once the values are defined as it suits your desired outcome, we can proceed with the deployment of Velero using Helm3:

helm install --upgrade --values ./values.yaml

The Helm deployment will display the resources being created. If interested in looking further, you can view Velero’s server-side components by running:

#Check deployed resources/crds
kubectl get all -n velero#Check Logs
kubectl logs deployment/velero -n velero

Velero Client

The Velero CLI is required to operate data Backups and restore. Please download the latest tarball and extract it to a proper location as explained below:

wget https://github.com/vmware-tanzu/velero/releases/download/vX.Y.Z/RELEASE-TARBALL-NAME.tar.gztar -xvf RELEASE-TARBALL-NAME.tar.gz
sudo mv velero /usr/loca/bin; sudo chmod +x /usr/local/bin/velero#Verify the client installation
velero version#Enable Velero-CLI autocompletion (Optional)
echo 'source <(velero completion bash)' >>~/.bashrc
sudo velero completion bash >/etc/bash_completion.d/velero

Velero Client requires a locally stored KubeConfig file.

&!Finish

By default, Velero is installed/configured in the Velero namespace. If a different namespace is used during deployment, you can easily adapt/configure the Velero client:

velero client config set namespace=velero-backup -n velero-backup

Please check Part 2 of the Data Protection series to get an advanced view on how to perform backup/restores for several scenarios (Data corruption, Cluster Failure).

Stay posted; A detailed backup/restore operation-based post will soon be released.