forked from docs/doc-exports
Dong, Qiu Jian
86fb05065f
Reviewed-by: Eotvos, Oliver <oliver.eotvos@t-systems.com> Co-authored-by: Dong, Qiu Jian <qiujiandong1@huawei.com> Co-committed-by: Dong, Qiu Jian <qiujiandong1@huawei.com>
69 lines
15 KiB
HTML
69 lines
15 KiB
HTML
<a name="cce_bestpractice_0024"></a><a name="cce_bestpractice_0024"></a>
|
|
|
|
<h1 class="topictitle1">Migrating Resources in a Cluster</h1>
|
|
<div id="body0000001171703796"><div class="section" id="cce_bestpractice_0024__section0632163995516"><h4 class="sectiontitle">Application Scenarios</h4><p id="cce_bestpractice_0024__p6160124715555">WordPress is used as an example to describe how to migrate an application from an on-premises Kubernetes cluster to a CCE cluster. The WordPress application consists of the WordPress and MySQL components, which are containerized. The two components are bound to two local storage volumes of the Local type respectively and provide external access through the NodePort Service.</p>
|
|
<p id="cce_bestpractice_0024__p115616459247">Before the migration, use a browser to access the WordPress site, create a site named <strong id="cce_bestpractice_0024__b77331014112012">Migrate to CCE</strong>, and publish an article to verify the integrity of PV data after the migration. The article published in WordPress will be stored in the <strong id="cce_bestpractice_0024__b19549114712015">wp_posts</strong> table of the MySQL database. If the migration is successful, all contents in the database will be migrated to the new cluster. You can verify the PV data migration based on the migration result.</p>
|
|
</div>
|
|
<div class="section" id="cce_bestpractice_0024__section172731632154715"><h4 class="sectiontitle">Prerequisites</h4><ul id="cce_bestpractice_0024__ul178289225471"><li id="cce_bestpractice_0024__li10515100098">Before the migration, clear the abnormal pod resources in the source cluster. If the pod is in the abnormal state and has a PVC mounted, the PVC is in the pending state after the cluster is migrated.</li><li id="cce_bestpractice_0024__li8517155211119">Ensure that the cluster on the CCE side does not have the same resources as the cluster to be migrated because Velero does not restore the same resources by default.</li><li id="cce_bestpractice_0024__li1436416144524">To ensure that container images can be properly pulled after cluster migration, migrate the images to SWR.</li><li id="cce_bestpractice_0024__li1122702481914">CCE does not support EVS disks of the <strong id="cce_bestpractice_0024__b69136231580">ReadWriteMany</strong> type. If resources of this type exist in the source cluster, change the storage type to <strong id="cce_bestpractice_0024__b6248204013812">ReadWriteOnce</strong>.</li><li id="cce_bestpractice_0024__li14227112441912">Velero cannot back up or restore HostPath volumes. For details, see <a href="https://velero.io/docs/v1.13/file-system-backup/#limitations" target="_blank" rel="noopener noreferrer">Limitations</a>. To back up storage volumes of this type, replace the hostPath volumes with local volumes. If a backup task involves storage of the HostPath type, the storage volumes of this type will be automatically skipped and a warning message will be generated. This will not cause a backup failure.</li></ul>
|
|
</div>
|
|
<div class="section" id="cce_bestpractice_0024__section750718193288"><a name="cce_bestpractice_0024__section750718193288"></a><a name="section750718193288"></a><h4 class="sectiontitle">Backing Up Applications in the Source Cluster</h4><ol id="cce_bestpractice_0024__ol13869175012815"><li id="cce_bestpractice_0024__li686918502812"><a name="cce_bestpractice_0024__li686918502812"></a><a name="li686918502812"></a><span>(Optional) To back up the data of a specified storage volume in the pod, add an annotation to the pod. The annotation template is as follows:</span><p><pre class="screen" id="cce_bestpractice_0024__screen1621514549277">kubectl -n <strong id="cce_bestpractice_0024__b18471511300"><namespace</strong><strong id="cce_bestpractice_0024__b1437915916323">></strong> annotate <pod/<strong id="cce_bestpractice_0024__b8513833018">pod_name</strong>> backup.velero.io/backup-volumes=<strong id="cce_bestpractice_0024__b2058671816322"><volume_name_1></strong>,<strong id="cce_bestpractice_0024__b8147102610320"><volume_name_2></strong>,...</pre>
|
|
<ul id="cce_bestpractice_0024__ul787332554013"><li id="cce_bestpractice_0024__li17873725124015"><strong id="cce_bestpractice_0024__b991653818272"><namespace></strong>: namespace where the pod is located.</li><li id="cce_bestpractice_0024__li91571452104016"><strong id="cce_bestpractice_0024__b4133105572713"><pod_name></strong>: pod name.</li><li id="cce_bestpractice_0024__li17289162413"><strong id="cce_bestpractice_0024__b2645165910274"><volume_name></strong>: name of the persistent volume mounted to the pod. You can run the <strong id="cce_bestpractice_0024__b7672131818281">describe</strong> statement to query the pod information. The <strong id="cce_bestpractice_0024__b92329236285">Volume</strong> field indicates the names of all persistent volumes attached to the pod.</li></ul>
|
|
<p id="cce_bestpractice_0024__p59773463286">Add annotations to the pods of WordPress and MySQL. The pod names are <strong id="cce_bestpractice_0024__b111314504285">wordpress-758fbf6fc7-s7fsr</strong> and <strong id="cce_bestpractice_0024__b14571853152814">mysql-5ffdfbc498-c45lh</strong>. As the pods are in the default namespace <strong id="cce_bestpractice_0024__b360017234294">default</strong>, the <strong id="cce_bestpractice_0024__b195571126162920">-n <NAMESPACE></strong> parameter can be omitted.</p>
|
|
<pre class="screen" id="cce_bestpractice_0024__screen16790194410298">kubectl annotate pod/<strong id="cce_bestpractice_0024__b977317119301">wordpress-758fbf6fc7-s7fsr</strong> backup.velero.io/backup-volumes=<strong id="cce_bestpractice_0024__b15315124203312">wp-storage</strong>
|
|
kubectl annotate pod/<strong id="cce_bestpractice_0024__b1846113910331">mysql-5ffdfbc498-c45lh</strong> backup.velero.io/backup-volumes=<strong id="cce_bestpractice_0024__b84753445334">mysql-storage</strong></pre>
|
|
</p></li><li id="cce_bestpractice_0024__li184741221231"><span>Back up the application. During the backup, you can specify resources based on parameters. If no parameter is added, the entire cluster resources are backed up by default. For details about the parameters, see <a href="https://velero.io/docs/v1.13/resource-filtering/" target="_blank" rel="noopener noreferrer">Resource filtering</a>.</span><p><ul id="cce_bestpractice_0024__ul13885530152318"><li id="cce_bestpractice_0024__li189541343113814"><strong id="cce_bestpractice_0024__b631010291226">--default-volumes-to-fs-backup</strong>: indicates that the PV backup tool is used to back up all storage volumes attached to a pod. HostPath volumes are not supported. If this parameter is not specified, the storage volume specified by annotation in <a href="#cce_bestpractice_0024__li686918502812">1</a> is backed up by default. This parameter is available only when <span class="uicontrol" id="cce_bestpractice_0024__uicontrol116710184316"><b>--use-node-agent</b></span> is specified during <a href="cce_bestpractice_0310.html#cce_bestpractice_0310__li1722825643415">Velero installation</a>.<pre class="screen" id="cce_bestpractice_0024__screen339016477281">velero backup create <strong id="cce_bestpractice_0024__b3391124717289"><backup-name></strong> --default-volumes-to-fs-backup</pre>
|
|
</li><li id="cce_bestpractice_0024__li13885103020233"><strong id="cce_bestpractice_0024__b123935464395">--include-namespaces</strong>: backs up resources in a specified namespace.<pre class="screen" id="cce_bestpractice_0024__screen10218456192820">velero backup create <strong id="cce_bestpractice_0024__b321865692814"><backup-name></strong> --include-namespaces <strong id="cce_bestpractice_0024__b112181456132819"><namespace></strong></pre>
|
|
</li><li id="cce_bestpractice_0024__li1878363214300"><strong id="cce_bestpractice_0024__b1962311854016">--include-resources</strong>: backs up the specified resources.<pre class="screen" id="cce_bestpractice_0024__screen182801359172820">velero backup create <strong id="cce_bestpractice_0024__b16280135911286"><backup-name></strong> --include-resources <strong id="cce_bestpractice_0024__b132801959152815">deployments</strong></pre>
|
|
</li><li id="cce_bestpractice_0024__li279112398233"><strong id="cce_bestpractice_0024__b18831103874018">--selector</strong>: backs up resources that match the selector.<pre class="screen" id="cce_bestpractice_0024__screen996615142911">velero backup create <strong id="cce_bestpractice_0024__b1696710142919"><backup-name></strong> --selector <strong id="cce_bestpractice_0024__b89677111293"><key>=<value></strong></pre>
|
|
</li></ul>
|
|
<p id="cce_bestpractice_0024__p92264358479">In this section, resources in the namespace <strong id="cce_bestpractice_0024__b17851222194115">default</strong> are backed up. <strong id="cce_bestpractice_0024__b75041029144111">wordpress-backup</strong> is the backup name. Specify the same backup name when restoring applications. An example is as follows:</p>
|
|
<pre class="screen" id="cce_bestpractice_0024__screen06891528122912">velero backup create <strong id="cce_bestpractice_0024__b12689028112917">wordpress-backup</strong> --include-namespaces <strong id="cce_bestpractice_0024__b768982819295">default</strong> --default-volumes-to-fs-backup</pre>
|
|
<p id="cce_bestpractice_0024__p144623310522">If the following information is displayed, the backup task is successfully created:</p>
|
|
<pre class="screen" id="cce_bestpractice_0024__screen19371846194717">Backup request "wordpress-backup" submitted successfully.
|
|
Run `velero backup describe wordpress-backup` or `velero backup logs wordpress-backup` for more details.</pre>
|
|
</p></li><li id="cce_bestpractice_0024__li1346315753711"><span>Check the backup status.</span><p><pre class="screen" id="cce_bestpractice_0024__screen9602533192917">velero backup get</pre>
|
|
<div class="p" id="cce_bestpractice_0024__p13385551093">Information similar to the following is displayed:<pre class="screen" id="cce_bestpractice_0024__screen194819531693">NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
|
|
wordpress-backup Completed 0 0 2021-10-14 15:32:07 +0800 CST 29d default <none></pre>
|
|
</div>
|
|
<p id="cce_bestpractice_0024__p172822018101211">In addition, you can go to the object bucket to view the backup files. The backups path is the application resource backup path, and the other is the PV data backup path.</p>
|
|
<p id="cce_bestpractice_0024__p070010193464"><span><img id="cce_bestpractice_0024__image1182894315373" src="en-us_image_0000001851743956.png"></span></p>
|
|
</p></li></ol>
|
|
</div>
|
|
<div class="section" id="cce_bestpractice_0024__section482103142819"><a name="cce_bestpractice_0024__section482103142819"></a><a name="section482103142819"></a><h4 class="sectiontitle">Restoring Applications in the Target Cluster</h4><p id="cce_bestpractice_0024__p327511016415">The storage infrastructure of an on-premises cluster is different from that of a cloud cluster. After the cluster is migrated, PVs cannot be mounted to pods. Therefore, during the migration, update the storage class of the target cluster to shield the differences of underlying storage interfaces between the two clusters when creating a workload and request storage resources of the corresponding type. For details, see <a href="cce_bestpractice_0312.html#cce_bestpractice_0312__section746195321414">Updating the Storage Class</a>. </p>
|
|
<ol id="cce_bestpractice_0024__ol1479111811193"><li id="cce_bestpractice_0024__li2818156192318"><span>Use kubectl to connect to the CCE cluster. Create a storage class with the same name as that of the source cluster.</span><p><p id="cce_bestpractice_0024__p16147123103312">In this example, the storage class name of the source cluster is <strong id="cce_bestpractice_0024__b1230733411542">local</strong> and the storage type is local disk. Local disks completely depend on the node availability. The data DR performance is poor. When the node is unavailable, the existing storage data is affected. Therefore, EVS volumes are used as storage resources in CCE clusters, and SAS disks are used as backend storage media.</p>
|
|
<div class="note" id="cce_bestpractice_0024__note16252155165813"><img src="public_sys-resources/note_3.0-en-us.png"><span class="notetitle"> </span><div class="notebody"><ul id="cce_bestpractice_0024__ul20948324183318"><li id="cce_bestpractice_0024__li14948724153314">When an application containing PV data is restored in a CCE cluster, the defined storage class dynamically creates and mounts storage resources (such as EVS volumes) based on the PVC.</li><li id="cce_bestpractice_0024__li31252027143311">The storage resources of the cluster can be changed as required, not limited to EVS volumes. To mount other types of storage, such as file storage and object storage, see <a href="cce_bestpractice_0312.html#cce_bestpractice_0312__section746195321414">Updating the Storage Class</a>.</li></ul>
|
|
</div></div>
|
|
<p id="cce_bestpractice_0024__p7541929823">YAML file of the migrated cluster:</p>
|
|
<pre class="screen" id="cce_bestpractice_0024__screen563461684510">apiVersion: storage.k8s.io/v1
|
|
kind: StorageClass
|
|
metadata:
|
|
<strong id="cce_bestpractice_0024__b1219891116519">name: local</strong>
|
|
provisioner: kubernetes.io/no-provisioner
|
|
volumeBindingMode: WaitForFirstConsumer</pre>
|
|
<div class="p" id="cce_bestpractice_0024__p12916438619">The following is an example of the YAML file of the migration cluster:<pre class="screen" id="cce_bestpractice_0024__screen159154313617">allowVolumeExpansion: true
|
|
apiVersion: storage.k8s.io/v1
|
|
kind: StorageClass
|
|
metadata:
|
|
<strong id="cce_bestpractice_0024__b195715171158">name: local</strong>
|
|
selfLink: /apis/storage.k8s.io/v1/storageclasses/csi-disk
|
|
parameters:
|
|
csi.storage.k8s.io/csi-driver-name: disk.csi.everest.io
|
|
csi.storage.k8s.io/fstype: ext4
|
|
everest.io/disk-volume-type: <strong id="cce_bestpractice_0024__b9914438618">SAS</strong>
|
|
everest.io/passthrough: "true"
|
|
provisioner: everest-csi-provisioner
|
|
reclaimPolicy: Delete
|
|
volumeBindingMode: Immediate </pre>
|
|
</div>
|
|
</p></li><li id="cce_bestpractice_0024__li07918183190"><span>Use the Velero tool to create a restore and specify a backup named <strong id="cce_bestpractice_0024__b19649155385816">wordpress-backup</strong> to restore the WordPress application to the CCE cluster.</span><p><pre class="screen" id="cce_bestpractice_0024__screen14271750153013">velero restore create --from-backup <strong id="cce_bestpractice_0024__b127355023010">wordpress-backup</strong></pre>
|
|
<p id="cce_bestpractice_0024__p19761518814">You can run the <strong id="cce_bestpractice_0024__b216533021114">velero restore get</strong> statement to view the application restoration status.</p>
|
|
</p></li><li id="cce_bestpractice_0024__li1339614791812"><span>After the restoration is complete, check whether the application is running properly. If other adaptation problems may occur, rectify the fault by following the procedure described in <a href="cce_bestpractice_0312.html">Updating Resources Accordingly</a>.</span></li></ol>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="cce_bestpractice_0326.html">Procedure</a></div>
|
|
</div>
|
|
</div>
|
|
|