Updating Resources Accordingly

Updating Images

The WordPress and MySQL images used in this example can be pulled from SWR. Therefore, the image pull failure (ErrImagePull) will not occur. If the application to be migrated is created from a private image, perform the following operations to update the image:

1. Migrate the images to SWR. For details, see Pushing an Image.
2. Log in to the SWR console and obtain the image address after the migration.
   The image address is in the following format:

   'swr.{Region}.myhuaweicloud.com/{Organization name}/{Image name}:{Tag name}'

3. Run the following command to modify the workload and replace the image field in the YAML file with the image address:

   kubectl edit deploy wordpress

4. Check the workload status.

Updating Services

After the cluster is migrated, the Services in the source cluster may not work. You can perform the following operations to update the Service. If there are ingresses in the source cluster, you must re-associate them with load balancers after the migration. For details, see Creating a LoadBalancer Ingress Using kubectl.

1. Access the cluster using kubectl.
2. Edit the YAML file of the corresponding Service to change the Service type and port number.

   kubectl edit svc wordpress

   To update a LoadBalancer Service, re-associate it with the load balancer. Add the annotations by following the procedure in Using kubectl to Create a Service (Using an Existing Load Balancer).

   annotations: 
     kubernetes.io/elb.class: union # Shared load balancer
     kubernetes.io/elb.id: 9d06a39d-xxxx-xxxx-xxxx-c204397498a3    # Load balancer ID, which can be queried on the ELB console.
     kubernetes.io/elb.session-affinity-mode: SOURCE_IP    # Enable the sticky session based on the source IP address.

3. Use a browser to check whether the Service is available.

Updating Storage Classes

As the storage infrastructures of clusters may be different, storage volumes cannot be mounted to the target cluster. You can use either of the following methods to update the volumes:

Both update methods can be performed only before applications are restored to the target cluster. Otherwise, PV data may fail to restore. In this case, use Velero to restore applications after the storage class update is complete. For details, see Restoring the Application to the Target Cluster.

Method 1: Creating a ConfigMap mapping

1. Create a ConfigMap in the CCE cluster and map the storage classes used by the source cluster to the default storage classes of the CCE cluster.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: change-storageclass-plugin-config
     namespace: velero
     labels:
       app.kubernetes.io/name: velero
       velero.io/plugin-config: "true"
       velero.io/change-storage-class: RestoreItemAction
   data:
     {Storage class name01 in the source cluster}: {Storage class name01 in the target cluster}
     {Storage class name02 in the source cluster}: {Storage class name02 in the target cluster}

2. Apply the ConfigMap settings.

   kubectl create -f change-storage-class.yaml
   configmap/change-storageclass-plugin-config created

Method 2: Creating storage classes with the same name

1. Obtain the default storage classes supported by CCE.

   kubectl get sc

   Information similar to the following is displayed:

   csi-disk             everest-csi-provisioner         Delete          Immediate              true                   77d
   csi-disk-dss         everest-csi-provisioner         Delete          Immediate              true                   77d
   csi-disk-topology    everest-csi-provisioner         Delete          WaitForFirstConsumer   true                   77d
   csi-local            everest-csi-provisioner         Delete          Immediate              false                  19d
   csi-local-topology   everest-csi-provisioner         Delete          WaitForFirstConsumer   true                   19d
   csi-nas              everest-csi-provisioner         Delete          Immediate              true                   77d
   csi-obs              everest-csi-provisioner         Delete          Immediate              false                  77d
   csi-sfs              everest-csi-provisioner         Delete          Immediate              false                  77d
   csi-sfsturbo         everest-csi-provisioner         Delete          Immediate              true                   77d

   Table 1 Storage classes

   Storage Class	Storage Resource
   csi-disk	EVS disk
   csi-disk-topology	EVS disk with delayed binding
   csi-disk-dss	DSS disk
   csi-local	Local PV
   csi-local-topology	Local PV with delayed binding
   csi-nas	File system (SFS 1.0)
   csi-sfs	General purpose file system (SFS 3.0 Capacity-Oriented)
   csi-obs	OBS bucket
   csi-sfsturbo	SFS Turbo file system

2. Export the required storage class details in the YAML format.

   kubectl get sc <storageclass-name> -o=yaml

3. Copy the YAML file and create new storage classes.

   Change the storage class names to the names used in the source cluster to call basic storage resources on the cloud.

   The YAML file of csi-obs is used as an example. Delete unnecessary information, such as creationTimestamp, resourceVersion, selfLink, and uid, under the metadata field and change the name field. You are advised not to modify other parameters.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     creationTimestamp: "2021-10-18T06:41:36Z"
     name: <your_storageclass_name>     # Use the name of the storage class used in the source cluster.
     resourceVersion: "747"
     selfLink: /apis/storage.k8s.io/v1/storageclasses/csi-obs
     uid: 4dbbe557-ddd1-4ce8-bb7b-7fa15459aac7
   parameters:
     csi.storage.k8s.io/csi-driver-name: obs.csi.everest.io
     csi.storage.k8s.io/fstype: s3fs
     everest.io/obs-volume-type: STANDARD
   provisioner: everest-csi-provisioner
   reclaimPolicy: Delete
   volumeBindingMode: Immediate

   

   • SFS Turbo file systems cannot be directly created using storage classes. Go to the SFS Turbo console and create SFS Turbo file systems that belong to the same VPC subnet and have inbound ports (111, 445, 2049, 2051, 2052, and 20048) enabled in the security group.
   • CCE does not support EVS disks of the ReadWriteMany type. If resources of this type exist in the source cluster, change the storage type to ReadWriteOnce.

4. Restore the cluster application by referring to Restoring the Application to the Target Cluster and check whether the PVC has been created.

   kubectl get pvc

   In the command output, the VOLUME column indicates the name of the PV automatically created using the storage class.

   NAME   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   pvc    Bound    pvc-4c8e655a-1dbc-4897-ae6c-446b502f5e77   5Gi        RWX            local          13s

Updating Databases

A local MySQL database is used as an example. It does not need to be reconfigured after the migration. If you use DRS to migrate a local database to RDS, configure database access based on site requirements after the migration.

• If the RDS instance is in the same VPC as the CCE cluster, it can be accessed using the private IP address. If it is not, it can only be accessed through the Internet with an EIP. You are advised to use the private network access mode for high security and good RDS performance.
• Traffic from the cluster has been allowed in the inbound rule of the RDS security group. Otherwise, the access will fail.

1. Log in to the RDS console and obtain the private IP address and port number of the DB instance on the Summary page.
2. Modify the WordPress workload.

   kubectl edit deploy wordpress

   Configure the environment variables in the env field.

   • WORDPRESS_DB_HOST: address and port number used for accessing the database, that is, the internal network address and port number obtained in the previous step
   • WORDPRESS_DB_USER: username for accessing the database
   • WORDPRESS_DB_PASSWORD: password for accessing the database
   • WORDPRESS_DB_NAME: name of the database to be connected

3. Check whether the RDS database is properly connected.