This article describes how to restore backed-up Azure Kubernetes Service (AKS). You can also restore AKS cluster using Azure PowerShell.
Azure Backup now allows you to back up AKS clusters (cluster resources and persistent volumes attached to the cluster) using a backup extension, which must be installed in the cluster. Backup vault communicates with the cluster via this Backup Extension to perform backup and restore operations.
Before you startAKS backup allows you to restore to original AKS cluster (that was backed up) and to an alternate AKS cluster. AKS backup allows you to perform a full restore and item-level restore. You can utilize restore configurations to define parameters based on the cluster resources that are to be restored.
You must install the Backup Extension in the target AKS cluster. Also, you must enable Trusted Access between the Backup vault and the AKS cluster.
In case you are trying to restore a backup stored in Vault Tier, you need to provide a storage account in input as a staging location. Backup data is stored in the Backup vault as a blob within the Microsoft tenant. During a restore operation, the backup data is copied from one vault to staging storage account across tenants. Ensure that the staging storage account for the restore has the AllowCrossTenantReplication property set to true.
Azure Backup does not automatically scale out AKS nodesâit only restores data and associated resources. Autoscaling is managed by AKS itself, using features like the Cluster Autoscaler. If autoscaling is enabled on the target cluster, it should handle resource scaling automatically. Before restoring, ensure that the target cluster has sufficient resources to avoid restore failures or performance issues
For more information on the limitations and supported scenarios, see the support matrix.
Restore the AKS clustersTo restore the backed-up AKS cluster, follow these steps:
Go to Backup center and select Restore.
On the next page, select Select backup instance, and then select the instance that you want to restore.
If the instance is available in both Primary and Secondary Region, select the region to restore too, and then select Continue.
Click Select restore point to select the restore point you want to restore.
If the restore point is available in both Vault and Operation datastore, select the one you want to restore from.
In the Restore parameters section, click Select Kubernetes Service and select the AKS cluster to which you want to restore the backup to.
To select the backed-up cluster resources for restore, click Select resources.
Learn more about restore configurations.
If you selected a recovery point for restore from Vault-standard datastore, then provide a snapshot resource group and storage account as the staging location.
Note
Currently, resources created in the staging location can't belong within a Private Endpoint. Ensure that you enable public access on the storage account provided as a staging location.
Select Validate to run validation on the cluster selections for restore.
Once the validation is successful, select Review + restore and restore the backups to the selected cluster.
As part of item-level restore capability of AKS backup, you can utilize multiple restore configuration filters to perform restore.
Select the Namespaces that you want to restore from the list. The list shows only the backed-up Namespaces.
You can also select the checkboxes if you want to restore cluster scoped resources and persistent volumes (of Azure Disk only).
To restore specific cluster resources, use the labels attached to them in the textbox. Only resources with the entered labels are backed up.
You can provide API Groups and Kinds to restore specific resource types. The list of API Group and Kind is available in the Appendix. You can enter multiple API Groups.
To restore a workload, such as Deployment from a backup via API Group, the entry should be:
Kind: Select Deployment.
Group: Select Group.
Namespace Mapping: To migrate the backed-up cluster resources to a different Namespace, select the backed-up Namespace, and then enter the Namespace to which you want to migrate the resources.
If the Namespace doesn't exist in the AKS cluster, it gets created. If a conflict occurs during the cluster resources restore, you can skip or patch the conflicting resources.
Azure Backup for AKS currently supports the following two options when doing a restore operation when resource clash happens (backed-up resource has the same name as the resource in the target AKS cluster). You can choose one of these options when defining the restore configuration.
Skip: This option is selected by default. For example, if you backed up a PVC named pvc-azuredisk and you're restoring it in a target cluster that has the PVC with the same name, then the backup extension skips restoring the backed-up persistent volume claim (PVC). In such scenarios, we recommend you to delete the resource from the cluster, and then do the restore operation.
Patch: This option allows the patching mutable variable in the backed-up resource on the resource in the target cluster. If you want to update the number of replicas in the target cluster, you can opt for patching as an operation.
Note
AKS backup currently doesn't delete and recreate resources in the target cluster if they already exist. If you attempt to restore Persistent Volumes in the original location, delete the existing Persistent Volumes, and then do the restore operation.
Restore in secondary regionTo restore the AKS cluster in the secondary region, configure Geo redundancy and Cross Region Restore in the Backup vault, and then trigger restore.
Next stepsRetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4