Help Center> Cloud Container Engine> User Guide> Old Console> Clusters> Upgrading a Cluster> Migrating Services Across Clusters of Different Versions
View PDF

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

Table 1 Checklist before migration

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
  1. Check whether the storage in use is provisioned by the public cloud or by the customer.
  2. Change the automatically created storage to the existing storage in the new cluster.

Network
  1. Pay special attention to the ELB and ingress.
  2. Clusters of an earlier version support only the classic load balancer. To migrate services to a new cluster, you need to change load balancer type to shared load balancer. Then, the corresponding ELB service will be re-established.

O&M

Private configuration: Check whether kernel parameters or system data have been configured on nodes in the cluster.

Procedure

  1. 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.

  2. Add a node.

    Add nodes with the same specifications and manual configuration items. For details, see Buying a Node.

  3. 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 (kubectl) Creating a PV from an Existing EVS Disk.

    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.

  4. 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 attach a storage volume to the workload, see (kubectl) Creating a Pod Mounted with an EVS Volume.

  5. Create a Service in the new cluster.

    The Service name and specifications remain unchanged. For details about how to create a Service, see Services.

  6. Commission services.

    After all resources are created, commission the containerized services. If the commissioning is successful, migrate the services to the new cluster.

  7. Delete or unsubscribe from the old cluster.

    After the new cluster is fully stable, unbind the associated storage volume. For details, see Unbinding an EVS Disk. Then, unsubscribe from or delete the old cluster. For details about how to delete a cluster, see Deleting a Cluster (Pay-per-Use).

Parent topic: Upgrading a Cluster