Migración de la versión 3 a la 4

Procedimiento

1. Coloque un componente de red exterior, como un equilibrador de carga de aplicaciones o un proxy inverso, entre los clientes y el clúster de destino.
2. Actualice el FQDN de la aplicación en el clúster de origen del servidor DNS para que devuelva la dirección IP del componente de red exterior.
3. Configure el componente de red para enviar las solicitudes recibidas para la aplicación en el dominio de origen al equilibrador de carga en el dominio del clúster de destino.
4. Cree un registro DNS comodín para el dominio *.apps.source.example.com que apunte a la dirección IP del equilibrador de carga del clúster de origen.
5. Cree un registro DNS para cada aplicación que apunte a la dirección IP del componente de red exterior frente al clúster de destino. Un registro DNS específico tiene mayor prioridad que un registro comodín, por lo que no surge ningún conflicto cuando se resuelve el FQDN de la aplicación.

1. Cree una ruta en el proyecto del clúster de destino que esté configurada para aceptar solicitudes dirigidas al FQDN de la aplicación en el clúster de origen:

   $ oc expose svc <app1-svc> --hostname <app1.apps.source.example.com> \
    -n <app1-namespace>

   Con esta nueva ruta, el servidor acepta cualquier solicitud para ese FQDN y la envía a los pods de la aplicación correspondientes. Además, cuando se migra la aplicación, se crea otra ruta en el dominio del clúster de destino. Las solicitudes llegan a la aplicación migrada utilizando cualquiera de estos nombres de host.

2. Cree un registro DNS con su proveedor de DNS que apunte el FQDN de la aplicación en el clúster de origen a la dirección IP del equilibrador de carga predeterminado del clúster de destino. Esto redirigirá el tráfico de su clúster de origen a su clúster de destino.

   El FQDN de la aplicación se resuelve en el equilibrador de carga del clúster de destino. El router del Controlador de Entrada por defecto acepta solicitudes para ese FQDN porque una ruta para ese nombre de host está expuesta.

1. Sustituya el certificado x509 del controlador de entrada predeterminado creado durante el proceso de instalación por un certificado personalizado.

2. Configure este certificado para que incluya los dominios DNS comodín de los clústeres de origen y destino en el campo subjectAltName.

   El nuevo certificado es válido para asegurar las conexiones realizadas con cualquiera de los dos dominios DNS.

Procedimiento

1. Obtenga el terminal S3, AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY ejecutando el comando describe en el recurso personalizado NooBaa.

   Estas credenciales se utilizan para añadir MCG como repositorio de replicación.

Procedimiento

1. Establezca la variable BUCKET:

   $ BUCKET=<your_bucket>

2. Establezca la variable REGION:

   $ REGION=<your_region>

3. Cree un bucket S3 de AWS:

   $ aws s3api create-bucket \
       --bucket $BUCKET \
       --region $REGION \
       --create-bucket-configuration LocationConstraint=$REGION 1

   1

   us-east-1 no admite LocationConstraint. Si su región es us-east-1, omita --create-bucket-configuration LocationConstraint=$REGION.

4. Cree el usuario IAM:

   $ aws iam create-user --user-name velero 1

   1

   Si quiere usar Velero para hacer copias de seguridad de varios clústeres con múltiples buckets de S3, cree un nombre de usuario único para cada clúster.

5. Cree un archivo velero-policy.json:

   $ cat > velero-policy.json <<EOF
   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "ec2:DescribeVolumes",
                   "ec2:DescribeSnapshots",
                   "ec2:CreateTags",
                   "ec2:CreateVolume",
                   "ec2:CreateSnapshot",
                   "ec2:DeleteSnapshot"
               ],
               "Resource": "*"
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:DeleteObject",
                   "s3:PutObject",
                   "s3:AbortMultipartUpload",
                   "s3:ListMultipartUploadParts"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}/*"
               ]
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:ListBucket"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}"
               ]
           }
       ]
   }
   EOF

6. Adjunte las políticas para conceder los permisos necesarios al usuario velero:

   $ aws iam put-user-policy \
     --user-name velero \
     --policy-name velero \
     --policy-document file://velero-policy.json

7. Cree la clave de acceso para el usuario velero:

   $ aws iam create-access-key --user-name velero

   Ejemplo de salida

   {
     "AccessKey": {
           "UserName": "velero",
           "Status": "Active",
           "CreateDate": "2017-07-31T22:24:41.576Z",
           "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
           "AccessKeyId": <AWS_ACCESS_KEY_ID>
     }
   }

   Registre AWS_SECRET_ACCESS_KEY y AWS_ACCESS_KEY_ID. Utilice las credenciales para añadir AWS como repositorio de replicación.

Procedimiento

1. Inicie sesión en GCP:

   $ gcloud auth login

2. Establezca la variable BUCKET:

   $ BUCKET=<bucket> 1

   1

   Especifica el nombre del bucket.

3. Cree el bucket de almacenamiento:

   $ gsutil mb gs://$BUCKET/

4. Establezca la variable PROJECT_ID para su proyecto activo:

   $ PROJECT_ID=$(gcloud config get-value project)

5. Cree una cuenta de servicio:

   $ gcloud iam service-accounts create velero \
       --display-name "Velero service account"

6. Enumere sus cuentas de servicio:

   $ gcloud iam service-accounts list

7. Establezca la variable SERVICE_ACCOUNT_EMAIL para que coincida con el valor de su correo electrónico:

   $ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
       --filter="displayName:Velero service account" \
       --format 'value(email)')

8. Adjunte las políticas para conceder los permisos necesarios al usuario velero:

   $ ROLE_PERMISSIONS=(
       compute.disks.get
       compute.disks.create
       compute.disks.createSnapshot
       compute.snapshots.get
       compute.snapshots.create
       compute.snapshots.useReadOnly
       compute.snapshots.delete
       compute.zones.get
   )

9. Cree el rol personalizado velero.server:

   $ gcloud iam roles create velero.server \
       --project $PROJECT_ID \
       --title "Velero Server" \
       --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"

10. Añada la vinculación de la política IAM al proyecto:

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server

11. Actualice la cuenta de servicio IAM:

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}

12. Guarde las claves de la cuenta de servicio IAM en el archivo credentials-velero en el directorio actual:

    $ gcloud iam service-accounts keys create credentials-velero \
        --iam-account $SERVICE_ACCOUNT_EMAIL

    Utilice el archivo credentials-velero para añadir GCP como repositorio de replicación.

Procedimiento

1. Inicie sesión en Azure:

   $ az login

2. Establezca la variable AZURE_RESOURCE_GROUP:

   $ AZURE_RESOURCE_GROUP=Velero_Backups

3. Cree un grupo de recursos de Azure:

   $ az group create -n $AZURE_RESOURCE_GROUP --location CentralUS 1

   1

   Especifique su ubicación.

4. Establezca la variable AZURE_STORAGE_ACCOUNT_ID:

   $ AZURE_STORAGE_ACCOUNT_ID="velero$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"

5. Cree una cuenta de almacenamiento de Azure:

   $ az storage account create \
       --name $AZURE_STORAGE_ACCOUNT_ID \
       --resource-group $AZURE_BACKUP_RESOURCE_GROUP \
       --sku Standard_GRS \
       --encryption-services blob \
       --https-only true \
       --kind BlobStorage \
       --access-tier Hot

6. Establezca la variable BLOB_CONTAINER:

   $ BLOB_CONTAINER=velero

7. Cree un contenedor de almacenamiento de Azure Blob:

   $ az storage container create \
     -n $BLOB_CONTAINER \
     --public-access off \
     --account-name $AZURE_STORAGE_ACCOUNT_ID

8. Cree un servicio principal y credenciales para velero:

   $ AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv` \
     AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv` \
     AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" \
     --role "Contributor" --query 'password' -o tsv` \
     AZURE_CLIENT_ID=`az ad sp list --display-name "velero" \
     --query '[0].appId' -o tsv`

9. Guarde las credenciales de la entidad principal de servicio en el archivo credentials-velero:

   $ cat << EOF > ./credentials-velero
   AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
   AZURE_TENANT_ID=${AZURE_TENANT_ID}
   AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
   AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
   AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
   AZURE_CLOUD_NAME=AzurePublicCloud
   EOF

   Utilice el archivo credentials-velero para añadir Azure como repositorio de replicación.

Procedimiento

1. Obtenga el terminal S3, AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY ejecutando el comando describe en el recurso personalizado NooBaa.

Procedimiento

1. Inicie sesión en el clúster de OpenShift Container Platform en el que ha instalado MTC.

2. Obtenga la URL de la consola web de MTC introduciendo el siguiente comando:

   $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

   El resultado se parece al siguiente: https://migration-openshift-migration.apps.cluster.openshift.com.

3. Inicie un navegador y navegue hasta la consola web de MTC.

   Nota

   Si intenta acceder a la consola web de MTC inmediatamente después de instalar el operador de Migration Toolkit for Containers, es posible que la consola no se cargue porque el operador todavía está configurando el clúster. Espere unos minutos y vuelva a intentarlo.

4. Si utiliza certificados de CA autofirmados, se le pedirá que acepte el certificado de CA del servidor API del clúster de origen. La página web lo guiará a través del proceso de aceptación de los certificados restantes.
5. Inicie sesión con su nombre de usuario y contraseña de OpenShift Container Platform.

Procedimiento

1. Inicie sesión en el clúster.

2. Obtenga el token de la cuenta de servicio migration-controller:

   $ oc sa get-token migration-controller -n openshift-migration

   Ejemplo de salida

   eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ

3. En la consola web de MTC, haga clic en Clusters (Clústeres).
4. Haga clic en Add cluster (Añadir clúster).

5. Complete los siguientes campos:

   • Nombre del clúster: el nombre del clúster puede contener letras minúsculas (a-z) y números (0-9). No debe contener espacios ni caracteres internacionales.
   • URL: especifique la URL del servidor API, por ejemplo, https://<www.example.com>:8443.
   • Token de la cuenta de servicio: pegue el token de la cuenta de servicio migration-controller.

   • Ruta expuesta del host al registro de imágenes: si utiliza la migración directa de imágenes, especifique la ruta expuesta al registro de imágenes del clúster de origen.

     Para crear la ruta, ejecute el siguiente comando:

     • Para OpenShift Container Platform 3:

       $ oc create route passthrough --service=docker-registry --port=5000 -n default

     • Para OpenShift Container Platform 4:

       $ oc create route passthrough --service=image-registry --port=5000 -n openshift-image-registry

   • Clúster de Azure: debe seleccionar esta opción si utiliza las instantáneas de Azure para copiar sus datos.
   • Grupo de recursos de Azure: este campo se muestra si se selecciona el clúster de Azure. Especifique el grupo de recursos de Azure.
   • Requiere verificación de SSL: (opcional) seleccione esta opción para verificar las conexiones SSL al clúster.
   • Archivo de paquete de CA: este campo se muestra si se selecciona Require SSL verification (Requiere verificación de SSL). Si ha creado un archivo de paquete de certificados de CA personalizado para los certificados autofirmados, haga clic en Browse (Examinar), seleccione el archivo de paquete de CA y cárguelo.

6. Haga clic en Add cluster (Añadir clúster).

   El clúster aparece en la lista Clusters (Clústeres).

Procedimiento

1. En la consola web de MTC, haga clic en Replication repositories (Repositorios de replicación).
2. Haga clic en Add repository (Añadir repositorio).

3. Seleccione un tipo de proveedor de almacenamiento y complete los siguientes campos:

   • AWS para proveedores de S3, incluidos AWS y MCG:

     • Nombre del repositorio de replicación: especifique el nombre del repositorio de replicación en la consola web de MTC.
     • Nombre del bucket de S3: especifique el nombre del bucket de S3.
     • Región del bucket de S3:especifique la región del bucket de S3. Es obligatorio para AWS S3. Es opcional para algunos proveedores de S3. Consulte la documentación del producto de su proveedor de S3 para conocer los valores esperados.
     • Terminal de S3: especifique la URL del servicio S3, no del bucket, por ejemplo, https://<s3-storage.apps.cluster.com>. Es obligatorio para un proveedor genérico de S3. Debe utilizar el prefijo https://.
     • Clave de acceso del proveedor de S3: especifique <AWS_SECRET_ACCESS_KEY> para AWS o la clave de acceso del proveedor de S3 para MCG y otros proveedores de S3.
     • Clave de acceso secreta del proveedor de S3: especifique <AWS_ACCESS_KEY_ID> para AWS o la clave de acceso secreta del proveedor de S3 para MCG y otros proveedores de S3.
     • Requiere verificación de SSL: desactive esta casilla si utiliza un proveedor genérico de S3.
     • Si ha creado un paquete de certificados de CA personalizado para los certificados autofirmados, haga clic en Browse (Examinar) y busque el archivo codificado en Base64.

   • GCP:

     • Nombre del repositorio de replicación: especifique el nombre del repositorio de replicación en la consola web de MTC.
     • Nombre del bucket de GCP: especifique el nombre del bucket de GCP.
     • Credencial de GCP de JSON Blob: especifique la cadena en el archivo credentials-velero.

   • Azure:

     • Nombre del repositorio de replicación: especifique el nombre del repositorio de replicación en la consola web de MTC.
     • Grupo de recursos de Azure: especifique el grupo de recursos de almacenamiento de Azure Blob.
     • Nombre de la cuenta de almacenamiento de Azure: especifique el nombre de la cuenta de almacenamiento de Azure Blob.
     • Credenciales de Azure (contenido del archivo INI): especifique la cadena en el archivo credentials-velero.
4. Haga clic en Add repository (Añadir repositorio) y espere la validación de la conexión.

5. Haga clic en Close (Cerrar).

   El nuevo repositorio aparece en la lista de repositorios de replicación.

Procedimiento

1. En la consola web de MTC, haga clic en Migration plans (Planes de migración).
2. Haga clic en Add migration plan (Añadir plan de migración).

3. Introduzca el nombre del plan.

   El nombre del plan de migración no debe superar los 253 caracteres alfanuméricos en minúsculas (a-z, 0-9) y no debe contener espacios ni guiones bajos (_).

4. Seleccione un clúster de origen, un clúster de destino y un repositorio.
5. Haga clic en Next (Siguiente).
6. Seleccione los proyectos para la migración.
7. Opcional: haga clic en el icono de edición junto a un proyecto para cambiar el espacio de nombres de destino.
8. Haga clic en Next (Siguiente).

9. Seleccione un tipo de migración para cada PV:

   • La opción Copy (Copiar) copia los datos del PV de un clúster de origen en el repositorio de replicación y, luego, restaura los datos en un PV recién creado con características similares en el clúster de destino.
   • La opción Move (Mover) desmonta un volumen remoto, por ejemplo, NFS, del clúster de origen, crea un recurso de PV en el clúster de destino que apunta al volumen remoto y, a continuación, monta el volumen remoto en el clúster de destino. Las aplicaciones que se ejecutan en el clúster de destino utilizan el mismo volumen remoto que utilizaba el clúster de origen.
10. Haga clic en Next (Siguiente).

11. Seleccione un método de copia para cada PV:

    • Lacopia de instantáneas hace una copia de seguridad y restaura los datos utilizando la funcionalidad de instantáneas del proveedor de la nube. Es significativamente más rápido que la copia de sistemas de archivos.

    • La copia de sistemas de archivos hace una copia de seguridad de los archivos en el clúster de origen y los restaura en el clúster de destino.

      El método de copia de sistemas de archivos es necesario para la migración directa de volúmenes.

12. Puede seleccionar Verify copy (Verificar copia) para verificar los datos migrados con la copia de sistemas de archivos. Los datos se verifican generando una suma de comprobación para cada archivo de origen y verificando la suma de comprobación después de la restauración. La verificación de los datos reduce considerablemente el rendimiento.

13. Seleccione una clase de almacenamiento de destino.

    Si ha seleccionado Copia de sistemas de archivos, puede cambiar la clase de almacenamiento de destino.

14. Haga clic en Next (Siguiente).

15. En la página de opciones de migración, se selecciona la opción de migración de imagen directa si se ha especificado una ruta de registro de imagen expuesta para el clúster de origen. La opción de migración directa de PV se selecciona si está migrando datos con la copia de sistemas de archivos.

    Las opciones de migración directa copian imágenes y archivos directamente del clúster de origen al de destino. Esta opción es mucho más rápida que copiar imágenes y archivos del cluster de origen al repositorio de replicación y, luego, del repositorio de replicación al clúster de destino.

16. Haga clic en Next (Siguiente).

17. Opcional: haga clic en Add Hook (Añadir enlace) para añadir un enlace al plan de migración.

    Un enlace ejecuta un código personalizado. Puede añadir hasta cuatro enlaces a un mismo plan de migración. Cada enlace se ejecuta durante un paso de migración diferente.

    1. Introduzca el nombre del enlace que se mostrará en la consola web.
    2. Si el enlace es una estrategia de Ansible, seleccione Ansible playbook (Estrategia de Ansible) y haga clic en Browse (Examinar) para cargar la estrategia o pegue el contenido de la estrategia en el campo.
    3. Opcional: especifique una imagen de tiempo de ejecución de Ansible si no está utilizando la imagen de enlace predeterminada.

    4. Si el enlace no es una estrategia de Ansible, seleccione Custom container image (Imagen de contenedor personalizada) y especifique el nombre de la imagen y la ruta.

       Una imagen de contenedor personalizada puede incluir estrategias de Ansible.

    5. Seleccione el clúster de origen o el clúster de destino.
    6. Introduzca el nombre de la cuenta de servicio y el espacio de nombres de la cuenta de servicio.

    7. Seleccione el paso de migración para el enlace:

       • Antes de la copia de seguridad: antes de realizar la copia de seguridad de la carga de trabajo de la aplicación en el clúster de origen
       • Después de la copia de seguridad: después de que la carga de trabajo de la aplicación se respalde en el clúster de origen
       • Antes de la restauración: antes de restaurar la carga de trabajo de la aplicación en el clúster de destino
       • Después de la restauración: después de restaurar la carga de trabajo de la aplicación en el clúster de destino
    8. Haga clic en Add (Añadir).

18. Haga clic en Finish (Finalizar).

    El plan de migración se muestra en la lista de planes de migración.

Procedimiento

1. Inicie sesión en la consola web de MTC y haga clic en Migration plans (Planes de migración).

2. Haga clic en el menú Options (Opciones) junto al plan de migración y seleccione una de las siguientes opciones en Migration (Migración):

   • La migración por etapas copia los datos del clúster de origen en el clúster de destino sin detener la aplicación.

   • La migración por transición detiene las transacciones en el clúster de origen y mueve los recursos al clúster de destino.

     Opcional: en el cuadro de diálogo Cutover migration (Migración por transición) puede desactivar la casilla de verificación Halt transactions on the source cluster during migration (Detener transacciones en el clúster de origen durante la migración).

   • La migración por etapas copia las reclamaciones de volúmenes persistentes (PVC) seleccionadas y los recursos de Kubernetes. Puede utilizar la migración por etapas para migrar un espacio de nombres dentro del mismo clúster.

     Importante

     No utilice la migración por etapas para migrar un espacio de nombres entre clústeres. Utilice en su lugar la migración por etapas o transición.

     • Seleccione una o más PVC en el cuadro de diálogo State migration (Migración de estado) y haga clic en Migrate (Migrar).

3. Una vez finalizada la migración, compruebe que la aplicación ha migrado correctamente en la consola web de OpenShift Container Platform:

   1. Haga clic en Home (Inicio) → Projects (Proyectos).
   2. Haga clic en el proyecto migrado para ver su estado.
   3. En la sección Routes (Rutas), haga clic en Location (Ubicación) para verificar que la aplicación esté funcionando, si es el caso.
   4. Haga clic en Workloads (Cargas de trabajo) → Pods para comprobar que los pods se ejecutan en el espacio de nombres migrado.
   5. Haga clic en Storage (Almacenamiento) → Persistent volumes (Volúmenes persistentes) para verificar que los volúmenes persistentes migrados estén correctamente aprovisionados.

Procedimiento

1. Obtenga el manifiesto del CR MigrationController:

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

2. Actualice los parámetros del proxy:

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: <migration_controller>
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1
     httpProxy: http://<username>:<password>@<ip>:<port> 2
     httpsProxy: http://<username>:<password>@<ip>:<port> 3
     noProxy: example.com 4

   1

   URL del proxy Stunnel para la migración directa de volúmenes.

   2

   URL del proxy para crear conexiones HTTP fuera del clúster. El esquema de la URL debe ser http.

   3

   URL del proxy para crear conexiones HTTPS fuera del clúster. Si no se especifica, se utiliza httpProxy para las conexiones HTTP y HTTPS.

   4

   Lista separada por comas de nombres de dominio de destino, dominios, direcciones IP u otros CIDR de red para excluir el proxy.

   Introduzca un dominio con . para que coincida solo con los subdominios. Por ejemplo, .y.com coincide con x.y.com, pero no con y.com. Utilice * para evitar el proxy en todos los destinos. Si escala a los trabajadores que no están incluidos en la red definida por el campo networking.machineNetwork[].cidr de la configuración de instalación, debe añadirlos a esta lista para evitar problemas de conexión.

   Este campo se ignora si no se establecen los campos httpProxy y httpsProxy.

3. Guarde el manifiesto como migration-controller.yaml.

4. Aplique el manifiesto actualizado:

   $ oc replace -f migration-controller.yaml -n openshift-migration

Procedimiento

1. Cree un manifiesto de CR de MigCluster para el clúster del host:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <host_cluster>
     namespace: openshift-migration
   spec:
     isHostCluster: true
   EOF

2. Cree un manifiesto de objetos Secret para cada clúster remoto:

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: <cluster_secret>
     namespace: openshift-config
   type: Opaque
   data:
     saToken: <sa_token> 1
   EOF

   1

   Especifique el token de la cuenta de servicio (SA) migration-controller codificado en base64 del clúster remoto. Puede obtener el token ejecutando el siguiente comando:

   $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0

3. Cree un manifiesto de CR de MigCluster para cada clúster remoto:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <remote_cluster> 1
     namespace: openshift-migration
   spec:
     exposedRegistryPath: <exposed_registry_route> 2
     insecure: false 3
     isHostCluster: false
     serviceAccountSecretRef:
       name: <remote_cluster_secret> 4
       namespace: openshift-config
     url: <remote_cluster_url> 5
   EOF

   1

   Especifique el CR de clúster del clúster remoto.

   2

   Opcional: para la migración directa de imágenes, especifique la ruta de registro expuesta.

   3

   La verificación de SSL se activa si es falsa. Los certificados de CA no son necesarios ni se comprueban si son verdaderos.

   4

   Especifique el objeto secreto del clúster remoto.

   5

   Especifique la URL del clúster remoto.

4. Compruebe que todos los clústeres tengan el estado Ready (Listo):

   $ oc describe cluster <cluster>

5. Cree un manifiesto de objetos Secret para el repositorio de replicación:

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     namespace: openshift-config
     name: <migstorage_creds>
   type: Opaque
   data:
     aws-access-key-id: <key_id_base64> 1
     aws-secret-access-key: <secret_key_base64> 2
   EOF

   1

   Especifique el ID de la clave en formato base64.

   2

   Especifique la clave secreta en formato base64.

   Las credenciales de AWS están codificadas en base64 por defecto. Para otros proveedores de almacenamiento, debe codificar sus credenciales ejecutando el siguiente comando con cada clave:

   $ echo -n "<key>" | base64 -w 0 1

   1

   Especifique el ID de la clave o la clave secreta. Ambas claves deben estar codificadas en base64.

6. Cree un manifiesto de CR de MigStorage para el repositorio de replicación:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigStorage
   metadata:
     name: <migstorage>
     namespace: openshift-migration
   spec:
     backupStorageConfig:
       awsBucketName: <bucket> 1
       credsSecretRef:
         name: <storage_secret> 2
         namespace: openshift-config
     backupStorageProvider: <storage_provider> 3
     volumeSnapshotConfig:
       credsSecretRef:
         name: <storage_secret> 4
         namespace: openshift-config
     volumeSnapshotProvider: <storage_provider> 5
   EOF

   1

   Especifique el nombre del bucket.

   2

   Especifique el CR Secrets del almacenamiento de objetos. Debe asegurarse de que las credenciales almacenadas en el CR Secrets del almacenamiento de objetos sean correctas.

   3

   Especifique el proveedor de almacenamiento.

   4

   Opcional: si copia los datos mediante el uso de instantáneas, especifique el CR Secrets del almacenamiento de objetos. Debe asegurarse de que las credenciales almacenadas en el CR Secrets del almacenamiento de objetos sean correctas.

   5

   Opcional: si copia los datos mediante el uso de instantáneas, especifique el proveedor de almacenamiento.

7. Compruebe que el CR MigStorage tenga el estado Ready (Listo):

   $ oc describe migstorage <migstorage>

8. Cree un manifiesto del CR MigPlan:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigPlan
   metadata:
     name: <migplan>
     namespace: openshift-migration
   spec:
     destMigClusterRef:
       name: <host_cluster>
       namespace: openshift-migration
     indirectImageMigration: true 1
     indirectVolumeMigration: true 2
     migStorageRef:
       name: <migstorage> 3
       namespace: openshift-migration
     namespaces:
       - <source_namespace_1> 4
       - <source_namespace_2>
       - <source_namespace_3>:<destination_namespace> 5
     srcMigClusterRef:
       name: <remote_cluster> 6
       namespace: openshift-migration
   EOF

   1

   La migración directa de imágenes se activa si es falsa.

   2

   La migración directa de volúmenes se activa si es falsa.

   3

   Especifique el nombre de la instancia de CR MigStorage.

   4

   Especifique uno o más espacios de nombres de origen. Por defecto, el espacio de nombres de destino tiene el mismo nombre.

   5

   Especifique un espacio de nombres de destino si es diferente del espacio de nombres de origen.

   6

   Especifique el nombre de la instancia MigCluster del clúster de origen.

9. Compruebe que la instancia MigPlan se encuentre en el estado Ready (Listo):

   $ oc describe migplan <migplan> -n openshift-migration

10. Cree un manifiesto de CR de MigMigration para iniciar la migración definida en la instancia MigPlan:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    EOF

    1

    Especifique el nombre del CR MigPlan.

    2

    Los pods del clúster de origen se detienen antes de la migración si son verdaderos.

    3

    Se realiza una migración por etapas que copia la mayor parte de los datos sin detener la aplicación si es verdadera.

    4

    Una migración completada se revierte si es verdadera.

11. Verifique la migración observando el progreso del CR MigMigration:

    $ oc watch migmigration <migmigration> -n openshift-migration

    El resultado se parece a lo siguiente:

    Ejemplo de salida

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       migplan
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

Procedimiento

1. Edite el manifiesto de recursos personalizados de MigrationController:

   $ oc edit migrationcontroller <migration_controller> -n openshift-migration

2. Actualice la sección de especificaciones añadiendo parámetros para excluir recursos específicos. Para aquellos recursos que no tienen sus propios parámetros de exclusión, añada el parámetro additional_excluded_resources:

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: migration-controller
     namespace: openshift-migration
   spec:
     disable_image_migration: true 1
     disable_pv_migration: true 2
     additional_excluded_resources: 3
     - resource1
     - resource2
     ...

   1

   Añada disable_image_migration: true para excluir los flujos de imágenes de la migración. imagestreams se añade a la lista excluded_resources en main.yml cuando se reinicia el pod de MigrationController.

   2

   Añada disable_pv_migration: true para excluir los PV del plan de migración. persistentvolumes y persistentvolumeclaims se añaden a la lista excluded_resources en main.yml cuando se reinicia el pod de MigrationController. Al desactivar la migración de FV también se desactiva la detección de FV cuando se crea el plan de migración.

   3

   Puede añadir los recursos de OpenShift Container Platform que desee excluir a la lista additional_excluded_resources.

3. Espere dos minutos a que se reinicie el pod de MigrationController para que se apliquen los cambios.

4. Compruebe que el recurso esté excluido:

   $ oc get deployment -n openshift-migration migration-controller -o yaml | grep EXCLUDED_RESOURCES -A1

   El resultado contiene los recursos excluidos:

   Ejemplo de salida

   name: EXCLUDED_RESOURCES
   value:
   resource1,resource2,imagetags,templateinstances,clusterserviceversions,packagemanifests,subscriptions,servicebrokers,servicebindings,serviceclasses,serviceinstances,serviceplans,imagestreams,persistentvolumes,persistentvolumeclaims

Procedimiento

1. Edite el manifiesto de recursos personalizados (CR) de MigrationController:

   $ oc edit migrationcontroller -n openshift-migration

2. Actualice los siguientes parámetros:

   ...
   mig_controller_limits_cpu: "1" 1
   mig_controller_limits_memory: "10Gi" 2
   ...
   mig_controller_requests_cpu: "100m" 3
   mig_controller_requests_memory: "350Mi" 4
   ...
   mig_pv_limit: 100 5
   mig_pod_limit: 100 6
   mig_namespace_limit: 10 7
   ...

   1

   Especifique el número de CPU disponibles para el CR MigrationController.

   2

   Especifique la cantidad de memoria disponible para el CR MigrationController.

   3

   Especifique el número de CPU disponibles para las solicitudes del CR MigrationController. 100m representa 0,1 unidades de CPU (100 * 1e-3).

   4

   Especifique la cantidad de memoria disponible para las solicitudes de CR de MigrationController.

   5

   Especifique el número de volúmenes persistentes que se pueden migrar.

   6

   Especifique el número de pods que se pueden migrar.

   7

   Especifique el número de espacios de nombres que se pueden migrar.

3. Cree un plan de migración que utilice los parámetros actualizados para verificar los cambios.

   Si su plan de migración supera los límites de CR de MigrationController, la consola de MTC muestra un mensaje de advertencia al guardar el plan de migración.

Procedimiento

1. Inicie la sesión en el clúster del host.

2. Habilite el redimensionamiento de los PV parcheando el CR MigrationController:

   $ oc patch migrationcontroller migration-controller -p '{"spec":{"enable_dvm_pv_resizing":true}}' \ 1
     --type='merge' -n openshift-migration

   1

   Establezca el valor en false para desactivar el redimensionamiento de PV.

3. Opcional: actualice el parámetro pv_resizing_threshold para aumentar el umbral:

   $ oc patch migrationcontroller migration-controller -p '{"spec":{"pv_resizing_threshold":41}}' \ 1
     --type='merge' -n openshift-migration

   1

   El valor por defecto es 3.

   Cuando se supera el umbral, se muestra el siguiente mensaje de estado en el estado del CR MigPlan:

   status:
     conditions:
   ...
     - category: Warn
       durable: true
       lastTransitionTime: "2021-06-17T08:57:01Z"
       message: 'Capacity of the following volumes will be automatically adjusted to avoid disk capacity issues in the target cluster:  [pvc-b800eb7b-cf3b-11eb-a3f7-0eae3e0555f3]'
       reason: Done
       status: "False"
       type: PvCapacityAdjustmentRequired

   Nota

   En el caso del almacenamiento de AWS gp2, este mensaje no aparece a menos que pv_resizing_threshold sea del 42 % o superior debido a la forma en que gp2 calcula el uso y el tamaño del volumen. (BZ#1973148)

Procedimiento

1. Habilite los clientes en caché ejecutando el siguiente comando:

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_enable_cache", "value": true}]'

2. Opcional: aumente los límites de memoria del CR MigrationController ejecutando el siguiente comando:

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_limits_memory", "value": <10Gi>}]'

3. Opcional: aumente las solicitudes de memoria del CR MigrationController ejecutando el siguiente comando:

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_requests_memory", "value": <350Mi>}]'

Procedimiento

1. En la consola web de MTC, haga clic en Migration Plans (Planes de migración).
2. Haga clic en el número de migraciones junto a un plan de migración para ver la página Migrations (Migraciones).
3. Haga clic en una migración para ver los detalles de la migración.

4. Expanda los recursos de migración para ver los recursos de migración y su estado en la vista de árbol.

   Nota

   Para solucionar una migración fallida, comience con un recurso de alto nivel que haya fallado y, luego, baje por el árbol de recursos hacia los recursos de nivel inferior.

5. Haga clic en el menú Options (Opciones) junto a un recurso y seleccione una de las siguientes opciones:

   • El comando Copy oc describe copia el comando en el portapapeles.

     • Inicie sesión en el clúster correspondiente y ejecute el comando.

       Las condiciones y los eventos del recurso se muestran en formato YAML.

   • El comando Copy oc logs copia el comando en el portapapeles.

     • Inicie sesión en el clúster correspondiente y ejecute el comando.

       Si el recurso admite el filtrado de registros, se muestra un registro filtrado.

   • En View JSON (Ver JSON) se muestran los datos del recurso en formato JSON en un navegador web.

     Los datos son los mismos que la salida del comando oc get <resource>.

Procedimiento

1. En la consola web de MTC, haga clic en Migration Plans (Planes de migración).
2. Haga clic en el número de migraciones junto a un plan de migración.
3. Haga clic en View logs (Ver registros).
4. Haga clic en el icono de copia para copiar el comando oc logs en el portapapeles.

5. Inicie sesión en el clúster correspondiente e introduzca el comando en la CLI.

   Se muestra el registro agregado del plan de migración.

Procedimiento

1. Obtenga el pod mig-log-reader:

   $ oc -n openshift-migration get pods | grep log

2. Introduzca el siguiente comando para mostrar un único registro de migración:

   $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1

   1

   En la opción -c plain se muestra el registro sin colores.

Procedimiento

1. En la consola web de OpenShift Container Platform, haga clic en Observe (Observar) → Metrics (Métricas).

2. Introduzca una consulta PromQL, seleccione una ventana de tiempo para mostrar y haga clic en Run Queries (Ejecutar consultas).

   Si su navegador web no muestra todos los resultados, utilice la consola de Prometheus.

Procedimiento

1. Navegue hasta el directorio en el que desea almacenar los datos que deben recopilarse.

2. Ejecute el comando oc adm must-gather para una de las siguientes opciones de recopilación de datos:

   • Para recopilar los datos de la última hora:

     $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.7

     Los datos se guardan como must-gather/must-gather.tar.gz. Puede subir este archivo a un caso de soporte en el Portal del cliente de Red Hat.

   • Para recopilar los datos de las últimas 24 horas:

     $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.7 \
       -- /usr/bin/gather_metrics_dump

     Esta operación puede llevar mucho tiempo. Los datos se guardan como must-gather/metrics/prom_data.tar.gz.

Procedimiento

1. Descomprima el archivo prom_data.tar.gz:

   $ tar -xvzf must-gather/metrics/prom_data.tar.gz

2. Cree una instancia local de Prometheus:

   $ make prometheus-run

   El comando muestra la URL de Prometheus.

   Resultado

   Started Prometheus on http://localhost:9090

3. Inicie un navegador web y navegue hasta la URL para ver los datos mediante la consola web de Prometheus.

4. Después de ver los datos, elimine la instancia y los datos de Prometheus:

   $ make prometheus-cleanup

Procedimiento

1. Compruebe el estado del CR MigMigration:

   $ oc get migmigration <migmigration> -o yaml

   Ejemplo de salida

   status:
     conditions:
     - category: Warn
       durable: true
       lastTransitionTime: "2021-01-26T20:48:40Z"
       message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
       status: "True"
       type: VeleroFinalRestorePartiallyFailed
     - category: Advisory
       durable: true
       lastTransitionTime: "2021-01-26T20:48:42Z"
       message: The migration has completed with warnings, please look at `Warn` conditions.
       reason: Completed
       status: "True"
       type: SucceededWithWarnings

2. Compruebe el estado del CR Restore mediante el comando describe de Velero:

   $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>

   Ejemplo de salida

   Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
   
   Errors:
     Velero:     <none>
     Cluster:    <none>
     Namespaces:
       migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource

3. Compruebe los registros del CR Restore utilizando el comando logs Velero:

   $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>

   Ejemplo de salida

   time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
   time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

   El mensaje de error de registro del CR Restore, el servidor no pudo encontrar el recurso solicitado, indica la causa de la migración parcialmente fallida.

Procedimiento

1. Enumera los CR de MigMigration en el espacio de nombres openshift-migration:

   $ oc get migmigration -n openshift-migration

   Ejemplo de salida

   NAME                                   AGE
   88435fe0-c9f8-11e9-85e6-5d593ce65e10   6m42s

2. Inspeccione el CR MigMigration:

   $ oc describe migmigration 88435fe0-c9f8-11e9-85e6-5d593ce65e10 -n openshift-migration

   El resultado es similar a los siguientes ejemplos.

Procedimiento

1. Asegúrese de que los registros internos estén expuestos en los clústeres de OpenShift Container Platform 3 y 4.

   El registro interno está expuesto por defecto en OpenShift Container Platform 4.

2. Si utiliza registros inseguros, añada los valores de su host de registro a la sección [registries.insecure] de /etc/container/registries.conf para asegurarse de que podman no encuentre un error de verificación de TLS.

3. Inicie sesión en el registro de OpenShift Container Platform 3:

   $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>

4. Inicie sesión en el registro de OpenShift Container Platform 4:

   $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>

5. Extraiga la imagen de OpenShift Container Platform 3:

   $ podman pull <registry_url>:<port>/openshift/<image>

6. Etiquete la imagen de OpenShift Container Platform 3 para el registro de OpenShift Container Platform 4:

   $ podman tag <registry_url>:<port>/openshift/<image> \ 1
     <registry_url>:<port>/openshift/<image> 2

   1

   Especifique la URL del registro y el puerto para el clúster de OpenShift Container Platform 3.

   2

   Especifique la URL del registro y el puerto para el clúster de OpenShift Container Platform 4.

7. Inserte la imagen en el registro de OpenShift Container Platform 4:

   $ podman push <registry_url>:<port>/openshift/<image> 1

   1

   Especifique el clúster de OpenShift Container Platform 4.

8. Compruebe que la imagen tenga un flujo de imagen válido:

   $ oc get imagestream -n openshift | grep <image>

   Ejemplo de salida

   NAME      IMAGE REPOSITORY                                                      TAGS    UPDATED
   my_image  image-registry.openshift-image-registry.svc:5000/openshift/my_image  latest  32 seconds ago

Procedimiento

1. Compruebe el estado del CR MigMigration:

   $ oc describe migmigration <pod> -n openshift-migration

   El resultado incluye el siguiente mensaje de estado:

   Ejemplo de salida

   Some or all transfer pods are not running for more than 10 mins on destination cluster

2. En el clúster de origen, obtenga los detalles del espacio de nombres migrado:

   $ oc get namespace <namespace> -o yaml 1

   1

   Especifique el espacio de nombres migrado.

3. En el clúster de destino, edite el espacio de nombres migrado:

   $ oc edit namespace <namespace>

4. Añada las anotaciones openshift.io/node-selector que faltan al espacio de nombres migrado, como en el siguiente ejemplo:

   apiVersion: v1
   kind: Namespace
   metadata:
     annotations:
       openshift.io/node-selector: "region=east"
   ...

5. Vuelva a ejecutar el plan de migración.

Procedimiento

1. En la consola web de MTC, haga clic en Migration plans (Planes de migración).
2. Haga clic en el menú Options (Opciones) al lado del plan de migración y seleccione Rollback (Retrotraer) en Migration (Migración).

3. Haga clic en Rollback (Retrotraer) y espere a que se complete el retroceso.

   En los detalles del plan de migración, se muestra Rollback succeeded (Retroceso exitoso).

4. Compruebe que el retroceso se haya realizado correctamente en la consola web de OpenShift Container Platform del clúster de origen:

   1. Haga clic en Home (Inicio) → Projects (Proyectos).
   2. Haga clic en el proyecto migrado para ver su estado.
   3. En la sección Routes (Rutas), haga clic en Location (Ubicación) para verificar que la aplicación esté funcionando, si es el caso.
   4. Haga clic en Workloads (Cargas de trabajo) → Pods para comprobar que los pods se ejecutan en el espacio de nombres migrado.
   5. Haga clic en Storage (Almacenamiento) → Persistent volumes (Volúmenes persistentes) para verificar que los volúmenes persistentes migrados estén correctamente aprovisionados.

Procedimiento

1. Cree un CR MigMigration basado en el siguiente ejemplo:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigMigration
   metadata:
     labels:
       controller-tools.k8s.io: "1.0"
     name: <migmigration>
     namespace: openshift-migration
   spec:
   ...
     rollback: true
   ...
     migPlanRef:
       name: <migplan> 1
       namespace: openshift-migration
   EOF

   1

   Especifique el nombre del CR MigPlan asociado.

2. En la consola web de MTC, compruebe que los recursos del proyecto migrado se hayan eliminado del clúster de destino.
3. Compruebe que los recursos del proyecto migrado estén presentes en el clúster de origen y que la aplicación se esté ejecutando.

Procedimiento

1. Elimine los pods de la etapa en todos los clústeres:

   $ oc delete $(oc get pods -l migration.openshift.io/is-stage-pod -n <namespace>) 1

   1

   Espacios de nombres especificados en el CR MigPlan.

2. Desactive la aplicación en el clúster de origen escalando las réplicas a su número antes de la migración:

   $ oc scale deployment <deployment> --replicas=<premigration_replicas>

   La anotación migration.openshift.io/preQuiesceReplicas en el CR Deployment muestra el número de réplicas antes de la migración:

   apiVersion: extensions/v1beta1
   kind: Deployment
   metadata:
     annotations:
       deployment.kubernetes.io/revision: "1"
       migration.openshift.io/preQuiesceReplicas: "1"

3. Verifique que los pods de la aplicación se ejecuten en el clúster de origen:

   $ oc get pod -n <namespace>