Solution Overview

Application Scenarios

Containers are growing in popularity and Kubernetes simplifies containerized deployment. Many companies choose to build their own Kubernetes clusters. However, the O&M workload of on-premises clusters is heavy, and O&M personnel need to configure the management systems and monitoring solutions by themselves. This increases the labor costs while decreasing the efficiency.

In terms of performance, an on-premises cluster has poor scalability due to its fixed specifications. Auto scaling cannot be implemented in case of traffic surges, which may easily result in the insufficient or waste of cluster resources. In addition, disaster recovery risks are not considered for deploying an on-premises cluster, leading to poor reliability. Once a fault occurs, the entire cluster may fail, resulting in serious production incidents.

Now you can address the preceding challenges by using CCE, a service that allows easy cluster management and flexible scaling, integrated with application service mesh and Helm charts to simplify cluster O&M and reduce operations costs. CCE is easy to use and delivers high performance, security, reliability, openness, and compatibility. This section describes the solution and procedure for migrating on-premises clusters to CCE.

Migration Solution

This section describes a cluster migration solution, which applies to the following types of clusters:

• Kubernetes clusters built in local IDCs
• On-premises clusters built using multiple ECSs
• Cluster services provided by other cloud service providers
• CCE clusters that are no longer maintained and cannot be upgraded in place

Figure 1 shows the migration process. You can migrate resources outside a cluster as required.

Figure 1 Migration solution diagram

Migration Process

The cluster migration process is as follows:

1. Plan resources for the target cluster.

   For details about the differences between CCE clusters and on-premises clusters, see Key Performance Parameter in Planning Resources for the Target Cluster. Plan resources as required and ensure that the performance configuration of the target cluster is the same as that of the source cluster.

2. Migrate resources outside a cluster.

   To migrate resources outside the cluster, see Migrating Resources Outside a Cluster.

3. Install the migration tool.

   After resources outside a cluster are migrated, you can use a migration tool to back up and restore application configurations in the source and target clusters. For details about how to install the tool, see Installing the Migration Tool.

4. Migrate resources in the cluster.

   Use Velero to back up resources in the source cluster to OBS and restore the resources in the target cluster. For details, see Migrating Resources in a Cluster.

   • Backing Up Applications in the Source Cluster

     To back up resources, use the Velero tool to create a backup object in the original cluster, query and back up cluster data and resources, package the data, and upload the package to the object storage that is compatible with the S3 protocol. Cluster resources are stored in the JSON format.

   • Restoring Applications in the Target Cluster

     During restoration in the target cluster, Velero specifies the temporary object bucket that stores the backup data, downloads the backup data to the new cluster, and redeploys resources based on the JSON file.

5. Update resources accordingly.

   After the migration, cluster resources may fail to be deployed. Update the faulty resources. The possible adaptation problems are as follows:

   • Updating Images
   • Updating Services
   • Updating the Storage Class
   • Updating Databases

6. Perform additional tasks.

   After cluster resources are properly deployed, verify application functions after the migration and switch service traffic to the target cluster. After confirming that all services are running properly, bring the source cluster offline.