Documentation for version v1.1.0 is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.
To configure Velero on Azure, you:
If you do not have the az
Azure CLI 2.0 installed locally, follow the
install guide to set it up.
Run:
az login
Ensure that the VMs for your agent pool allow Managed Disks. If I/O performance is critical, consider using Premium Managed Disks, which are SSD backed.
Download the latest official release’s tarball for your client platform.
We strongly recommend that you use an
official release of
Velero. The tarballs for each release contain the velero
command-line client. The code in the main branch
of the Velero repository is under active development and is not guaranteed to be stable!
Extract the tarball:
tar -xvf <RELEASE-TARBALL-NAME>.tar.gz -C /dir/to/extract/to
We’ll refer to the directory you extracted to as the “Velero directory” in subsequent steps.
Move the velero
binary from the Velero directory to somewhere in your PATH.
Velero requires a storage account and blob container in which to store backups.
The storage account can be created in the same Resource Group as your Kubernetes cluster or
separated into its own Resource Group. The example below shows the storage account created in a
separate Velero_Backups
Resource Group.
The storage account needs to be created with a globally unique id since this is used for dns. In
the sample script below, we’re generating a random name using uuidgen
, but you can come up with
this name however you’d like, following the
Azure naming rules for storage accounts. The
storage account is created with encryption at rest capabilities (Microsoft managed keys) and is
configured to only allow access via https.
Create a resource group for the backups storage account. Change the location as needed.
AZURE_BACKUP_RESOURCE_GROUP=Velero_Backups
az group create -n $AZURE_BACKUP_RESOURCE_GROUP --location WestUS
Create the storage account.
AZURE_STORAGE_ACCOUNT_ID="velero$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"
az storage account create \
--name $AZURE_STORAGE_ACCOUNT_ID \
--resource-group $AZURE_BACKUP_RESOURCE_GROUP \
--sku Standard_GRS \
--encryption-services blob \
--https-only true \
--kind BlobStorage \
--access-tier Hot
Create the blob container named velero
. Feel free to use a different name, preferably unique to a single Kubernetes cluster. See the
FAQ for more details.
BLOB_CONTAINER=velero
az storage container create -n $BLOB_CONTAINER --public-access off --account-name $AZURE_STORAGE_ACCOUNT_ID
Set the name of the Resource Group that contains your Kubernetes cluster’s virtual machines/disks.
WARNING: If you’re using
AKS, AZURE_RESOURCE_GROUP
must be set to the name of the auto-generated resource group that is created
when you provision your cluster in Azure, since this is the resource group that contains your cluster’s virtual machines/disks.
AZURE_RESOURCE_GROUP=<NAME_OF_RESOURCE_GROUP>
If you are unsure of the Resource Group name, run the following command to get a list that you can select from. Then set the AZURE_RESOURCE_GROUP
environment variable to the appropriate value.
az group list --query '[].{ ResourceGroup: name, Location:location }'
Get your cluster’s Resource Group name from the ResourceGroup
value in the response, and use it to set $AZURE_RESOURCE_GROUP
.
To integrate Velero with Azure, you must create a Velero-specific service principal.
Obtain your Azure Account Subscription ID and Tenant ID:
AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv`
AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv`
Create a service principal with Contributor
role. This will have subscription-wide access, so protect this credential.
If you’ll be using Velero to backup multiple clusters with multiple blob containers, it may be desirable to create a unique username per cluster rather than the default velero
.
Create service principal and let the CLI generate a password for you. Make sure to capture the password.
AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" --role "Contributor" --query 'password' -o tsv`
After creating the service principal, obtain the client id.
AZURE_CLIENT_ID=`az ad sp list --display-name "velero" --query '[0].appId' -o tsv`
Now you need to create a file that contains all the environment variables you just set. The command looks like the following:
cat << EOF > ./credentials-velero
AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
AZURE_TENANT_ID=${AZURE_TENANT_ID}
AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
EOF
Install Velero, including all prerequisites, into the cluster and start the deployment. This will create a namespace called velero
, and place a deployment named velero
in it.
velero install \
--provider azure \
--bucket $BLOB_CONTAINER \
--secret-file ./credentials-velero \
--backup-location-config resourceGroup=$AZURE_BACKUP_RESOURCE_GROUP,storageAccount=$AZURE_STORAGE_ACCOUNT_ID \
--snapshot-location-config apiTimeout=<YOUR_TIMEOUT>
Additionally, you can specify --use-restic
to enable restic support, and --wait
to wait for the deployment to be ready.
(Optional) Specify
additional configurable parameters for the --backup-location-config
flag.
(Optional) Specify
additional configurable parameters for the --snapshot-location-config
flag.
(Optional) Specify CPU and memory resource requests and limits for the Velero/restic pods.
For more complex installation needs, use either the Helm chart, or add --dry-run -o yaml
options for generating the YAML representation for the installation.
To help you get started, see the documentation.