Alauda Container Platform

Overview

After creating or accessing a cluster, it is recommended to back up cluster data regularly. Regular backups enable rapid recovery from unexpected incidents and facilitate cross-cluster data migration while ensuring data reliability.

Create a backup schedule by configuring the data types to be backed up (for example, cluster configuration data stored in ETCD and application data), data sources (nodes, namespaces), storage locations, backup methods, and rules. By triggering the schedule, the platform backs up cluster data according to the configured plan, enabling automatic backups on demand or on a defined schedule.

To restore cluster application data, execute an application recovery task based on existing backup files.

TOC

Usage scenarios

For different backup and recovery scenarios, configure backup policies and perform recovery as follows.

Backup and restore within the current Kubernetes cluster

When a local application fails (for example, a namespace is accidentally deleted), restore the application to the current cluster using the backup file. During recovery, application resources typically do not require modification (for example, domain names and service ports); restore the corresponding cluster resources only.

  1. Install the plugin: Install the backup and recovery plugin in the current cluster.

  2. Configure the backup repository: Configure the backup repository in the current cluster.

  3. Create a backup schedule: Create an application backup schedule in the current cluster. Select the namespaces that host the application and configure a periodic schedule.

  4. Run the recovery task: When recovery is required, run the application recovery task in the current cluster.

Cross-cluster application and data migration

Common cross-cluster backup and recovery scenarios include the following:

  • In traditional development and testing scenarios, applications may be migrated across data centers and restored from backup files to other clusters. After recovery, application resource adjustments may be required (for example, domain names and service ports).

  • Migration of cluster resources to other clusters.

  • Replication of production cluster resources to development and testing clusters.

Prerequisites

  • Ensure that the CPU, memory, and other specifications of the source and target clusters are similar. Large differences can prevent pods from being scheduled and leave them Pending after migration.

  • Ensure that the network mode of the source and target clusters is consistent; otherwise, some resources may not be restored properly during recovery. If subnets differ, pod IPs change after recovery.

Recommended approach

  1. Install the plugin: Install the backup and recovery plugin in the current cluster.

  2. Configure the backup repository: Configure the backup repository in the current cluster.

  3. Create a backup task: In the source cluster, create an application backup task, select the namespaces where the application is running, and configure a periodic schedule.

  4. Determine whether image migration is required: Before restoring data, assess whether image migration is needed. If the image repository is external to both clusters and accessible from both, this step is not required. For scenarios that require image migration, see Image Registry Replacement.

  5. Run the recovery task: In the target cluster, run the application recovery task.

  6. Import the namespace: After data migration, manually import the namespace into the corresponding project in Project Management. Otherwise, the recovered application may not be visible in the platform UI.

Cross-platform application and data migration

In cross-platform disaster recovery scenarios, when the primary platform cluster fails and workloads are switched to a cluster on the secondary platform, application adjustments may be required after migration (for example, domain names and service ports).

Prerequisites

  • Ensure that the CPU, memory, and other specifications of the source and target clusters are similar to avoid pods remaining unscheduled due to resource constraints.

  • Ensure that the network mode of the source and target clusters is consistent; otherwise, some resources may not be restored properly during recovery. If subnets differ, pod IPs change after recovery.

Recommended approach

  1. Install the plugin: Install the backup and recovery plugin in the current cluster.

  2. Configure the backup repository: Configure the backup repository in the current cluster.

  3. Create a backup task: In the cluster to be migrated, create an application backup policy, select the relevant namespaces, and configure a periodic schedule.

  4. Determine whether image migration is required: Before restoring data, assess whether image migration is needed. If the image repository is external to both clusters and accessible from both, this step can be skipped. For scenarios that require image migration, see Image Registry Replacement.

  5. Run the restore task: In the target cluster, run the application restore task.

  6. Import the namespace: After data migration, manually import the namespace into the corresponding project in Project Management. Otherwise, the restored application may not be visible in the platform UI.

View full docs as PDF