Migrating Services Across Clusters of Different Versions
Application Scenarios
This section describes how to migrate services from a cluster of an earlier version to a cluster of a later version in CCE.
This operation is applicable when a cross-version cluster upgrade is required (for example, upgrade from v1.7.* or v1.9.* to 1.17.*) and new clusters can be created for service migration.
Prerequisites
Category |
Description |
---|---|
Cluster |
NodeIP-related: Check whether node IP addresses (including EIPs) of the cluster before the migration have been used in other configurations or whitelists. |
Workloads |
Record the number of workloads for post-migration check. |
Storage |
|
O&M |
Private configuration: Check whether kernel parameters or system data have been configured on nodes in the cluster. |
Procedure
- Create a CCE cluster.
Create a cluster with the same specifications and configurations as the cluster of the earlier version. For details, see Buying a CCE Cluster.
- Add a node.
Add nodes with the same specifications and manual configuration items. For details, see Buying a Node.
- Create a storage volume in the new cluster.
Use an existing storage volume to create a PVC in the new cluster. The PVC name remains unchanged. For details, see PersistentVolumeClaims (PVCs).
Storage switching supports only OBS buckets, SFS file systems, and shared EVS disks. If a non-shared EVS disk is used, you need to suspend the workloads in the old cluster to switch the storage resources. As a result, services will be interrupted.
- Create a workload in the new cluster.
The workload name and specifications remain unchanged. For details about how to create a workload, see Creating a Deployment or Creating a StatefulSet. For details about how to mount a storage volume to the workload, see Creating a Pod Mounted with an EVS Volume.
- Create a Service in the new cluster.
The Service name and specifications remain unchanged. For details about how to create a Service, see Services.
- Commission services.
After all resources are created, commission the containerized services. If the commissioning is successful, migrate the services to the new cluster.
- Delete or unsubscribe from the old cluster.
When all functions of the new cluster are stable, unsubscribe from or delete the old cluster. For details about how to delete a cluster, see Deleting a Cluster (Pay-per-Use).
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.