Migrazione dalla versione 3 alla 4

Procedura

1. Posizionare un componente di rete esterno, come uno strumento di bilanciamento del carico o un proxy inverso, tra i client e il cluster di destinazione.
2. Aggiornare il FQDN dell'applicazione sul cluster di origine nel server DNS per restituire l'indirizzo IP del componente di rete esterno.
3. Configurare il componente di rete per inviare le richieste ricevute per l'applicazione nel dominio di origine allo strumento di bilanciamento del carico nel dominio del cluster di destinazione.
4. Creare un record DNS jolly per il dominio *.apps.source.example.com che punti all'indirizzo IP dello strumento di bilanciamento del carico del cluster di origine.
5. Creare un record DNS per ogni applicazione che punti all'indirizzo IP del componente di rete esterno di fronte al cluster di destinazione. Un record DNS specifico ha una priorità più alta di un record jolly, quindi non sorge alcun conflitto quando l'FQDN dell'applicazione viene risolto.

1. Creare un percorso nel progetto del cluster di destinazione che sia configurato per accettare richieste indirizzate all'FQDN dell'applicazione nel cluster di origine:

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

   Con questo nuovo percorso in funzione, il server accetta qualsiasi richiesta per quel FQDN e la invia ai pod dell'applicazione corrispondenti. Inoltre, quando si esegue la migrazione dell'applicazione, viene creato un altro percorso nel dominio del cluster di destinazione. Le richieste raggiungono l'applicazione migrata usando uno di questi nomi host.

2. Creare un record DNS con il provider DNS che punti l'FQDN dell'applicazione nel cluster di origine all'indirizzo IP dello strumento di bilanciamento del carico predefinito del cluster di destinazione. In questo modo si reindirizzerà il traffico dal cluster di origine al cluster di destinazione.

   L'FQDN dell'applicazione si risolve nello strumento di bilanciamento del carico del cluster di destinazione. Il router del controller di ingresso predefinito accetta le richieste per quel FQDN perché è esposto un percorso per quel nome host.

1. Sostituire il certificato x509 del controller di ingresso predefinito creato durante il processo di installazione con un certificato personalizzato.

2. Configurare questo certificato in modo da includere i domini DNS jolly per entrambi i cluster di origine e di destinazione nel campo subjectAltName.

   Il nuovo certificato è valido per proteggere le connessioni effettuate utilizzando entrambi i domini DNS.

Procedura

1. Ottenere l'endpoint S3, AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY eseguendo il comando describe sulla risorsa personalizzata NooBaa.

   Usare queste credenziali per aggiungere MCG come repository di replica.

Procedura

1. Impostare la variabile BUCKET:

   $ BUCKET=<your_bucket>

2. Impostare la variabile REGION:

   $ REGION=<your_region>

3. Creare un bucket AWS S3:

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

   1

   us-east-1 non supporta un LocationConstraint. Se l'area geografica è us-east-1, omettere --create-bucket-configuration LocationConstraint=$REGION.

4. Creare un utente IAM:

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

   1

   Se si desidera utilizzare Velero per eseguire il backup di più cluster con più bucket S3, creare un nome utente unico per ogni cluster.

5. Creare un file 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. Allegare i criteri per dare all'utente velero le autorizzazioni necessarie:

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

7. Creare una chiave di accesso per l'utente velero:

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

   Esempio di output

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

   Registrare AWS_SECRET_ACCESS_KEY e AWS_ACCESS_KEY_ID. Si utilizzano le credenziali per aggiungere AWS come repository di replica.

Procedura

1. Accedere a GCP:

   $ gcloud auth login

2. Impostare la variabile BUCKET:

   $ BUCKET=<bucket> 1

   1

   Specificare il nome del bucket.

3. Creare il bucket di storage:

   $ gsutil mb gs://$BUCKET/

4. Impostare la variabile PROJECT_ID nel progetto attivo:

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

5. Creare un account di servizio:

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

6. Elencare gli account di servizio:

   $ gcloud iam service-accounts list

7. Impostare la variabile SERVICE_ACCOUNT_EMAIL in modo che corrisponda al suo valore di email:

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

8. Allegare i criteri per dare all'utente velero le autorizzazioni necessarie:

   $ 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. Creare il ruolo personalizzato velero.server:

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

10. Aggiungere il binding del criterio IAM al progetto:

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

11. Aggiornare l'account di servizio IAM:

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

12. Salvare le chiavi dell'account di servizio IAM nel file credentials-velero nella directory corrente:

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

    Si utilizza il file credentials-velero per aggiungere GCP come repository di replica.

Procedura

1. Accedere ad Azure:

   $ az login

2. Impostare la variabile AZURE_RESOURCE_GROUP:

   $ AZURE_RESOURCE_GROUP=Velero_Backups

3. Creare un gruppo di risorse Azure:

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

   1

   Specificare la propria posizione.

4. Impostare la variabile AZURE_STORAGE_ACCOUNT_ID:

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

5. Creare un account di storage 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. Impostare la variabile BLOB_CONTAINER:

   $ BLOB_CONTAINER=velero

7. Creare un container di storage Azure Blob:

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

8. Creare un'entità servizio e le credenziali per 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. Salvare le credenziali dell'entità servizio nel file 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

   Si utilizza il file credentials-velero per aggiungere Azure come repository di replica.

Procedura

1. Ottenere l'endpoint S3, AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY eseguendo il comando describe sulla risorsa personalizzata NooBaa.

Procedura

1. Accedere al cluster di OpenShift Container Platform su cui è installato MTC.

2. Ottenere l'URL della console web di MTC inserendo il seguente comando:

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

   L'output assomiglia al seguente: https://migration-openshift-migration.apps.cluster.openshift.com.

3. Lanciare un browser e andare alla console web di MTC.

   Nota

   Se provi ad accedere alla console web di MTC subito dopo aver installato Migration Toolkit for Containers Operator, la console potrebbe non caricarsi perché l'Operator sta ancora configurando il cluster. Aspettare qualche minuto e riprovare.

4. Se si utilizzano certificati CA autofirmati, verrà richiesto di accettare il certificato CA del server API del cluster di origine. La pagina web ti guida attraverso il processo di accettazione dei certificati rimanenti.
5. Accedere con il nome utente e password di OpenShift Container Platform.

Procedura

1. Accedere al cluster.

2. Ottenere il token dell'account di servizio del migration-controller:

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

   Esempio di output

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

3. Nella console web di MTC, cliccare su Cluster.
4. Cliccare su Add cluster.

5. Compilare i seguenti campi:

   • Nome del cluster: il nome del cluster può contenere lettere minuscole(a-z) e numeri (0-9). Non deve contenere spazi o caratteri internazionali.
   • URL: specificare l'URL del server API, per esempio, https://<www.example.com>:8443.
   • Token dell'account di servizio: incollare il token dell'account di servizio migration-controller.

   • Host percorso esposto al registro delle immagini: se si utilizza la migrazione diretta delle immagini, specificare il percorso esposto al registro delle immagini del cluster di origine.

     Per creare il percorso, eseguire il seguente comando:

     • Per OpenShift Container Platform 3:

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

     • Per OpenShift Container Platform 4:

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

   • Cluster Azure: è necessario selezionare questa opzione se si utilizzano gli snapshot di Azure per copiare i dati.
   • Gruppo di risorse Azure: questo campo viene visualizzato se è selezionata l'opzione cluster Azure. Specificare il gruppo di risorse Azure.
   • Require SSL verification: Facoltativo: selezionare questa opzione per verificare le connessioni SSL al cluster.
   • File bundle CA: questo campo viene visualizzato se è selezionata l'opzione Require SSL verification. Se si è creato un file bundle del certificato CA personalizzato per i certificati autofirmati, cliccare su Browse, selezionare il file bundle CA e caricarlo.

6. Cliccare su Add cluster.

   Il cluster appare nell'elenco Clusters.

Procedura

1. Nella console web di MTC, cliccare su Replication repositories.
2. Cliccare su Add repository.

3. Selezionare un tipo di provider di storage e compilare i seguenti campi:

   • AWS per i provider S3, compresi AWS e MCG:

     • Nome del repository di replica: specificare il nome del repository di replica nella console web di MTC.
     • Nome bucket S3: specificare il nome del bucket S3.
     • Area geografica del bucket S3: specificare l'area geografica del bucket S3. Richiesto per AWS S3. Facoltativo per alcuni provider S3. Controllare la documentazione del prodotto del provider S3 per i valori attesi.
     • Endpoint S3: specificare l'URL del servizio S3, non il bucket, per esempio, https://<s3-storage.apps.cluster.com>. Required per un provider S3 generico. Occorre usare il prefisso https://.
     • Chiave di accesso del provider S3: specificare la chiave <AWS_SECRET_ACCESS_KEY> per AWS o la chiave di accesso del provider S3 per MCG e altri provider S3.
     • Chiave di accesso segreta del provider S3: specificare l'ID <AWS_ACCESS_KEY_ID> per AWS o la chiave di accesso segreta del provider S3 per MCG e altri provider S3.
     • Require SSL verification: deselezionare questa casella di controllo se si utilizza un provider S3 generico.
     • Se si è creato un bundle di certificati CA personalizzati per i certificati autofirmati, cliccare su Browse e cercare il file con codifica Base64.

   • GCP:

     • Nome del repository di replica: specificare il nome del repository di replica nella console web di MTC.
     • Nome bucket GCP: specificare il nome del bucket GCP.
     • Blob JSON delle credenziali GCP: specificare la stringa nel file credentials-velero.

   • Azure:

     • Nome del repository di replica: specificare il nome del repository di replica nella console web di MTC.
     • Gruppo di risorse Azure: specificare il gruppo di risorse dello storage Azure Blob.
     • Nome account di storage Azure: specificare il nome account dello storage Azure Blob.
     • Credenziali Azure - contenuto del file INI: specificare la stringa nel file credentials-velero.
4. Cliccare su Add repository e aspettare la convalida della connessione.

5. Cliccare su Close.

   Il nuovo repository appare nella lista Replication repositories.

Procedura

1. Nella console web di MTC, cliccare su Migration plans.
2. Cliccare su Add migration plan.

3. Inserire il nome del piano.

   Il nome del piano di migrazione non deve superare i 253 caratteri alfanumerici minuscoli (a-z, 0-9) e non deve contenere spazi o trattino basso (_).

4. Selezionare un cluster di origine, un cluster di destinazione e un repository.
5. Cliccare su Next.
6. Selezionare i progetti per la migrazione.
7. Facoltativo: cliccare sull'icona di modifica accanto a un progetto per cambiare lo spazio dei nomi di destinazione.
8. Cliccare su Next.

9. Selezionare un tipo di migrazione per ogni PV:

   • L'opzione Copy copia i dati dal PV di un cluster di origine al repository di replica e poi ripristina i dati su un PV appena creato, con caratteristiche simili, nel cluster di destinazione.
   • L'opzione Move smonta un volume remoto, per esempio NFS, dal cluster di origine, crea una risorsa PV sul cluster di destinazione che punta al volume remoto, e poi monta il volume remoto sul cluster di destinazione. Le applicazioni in esecuzione sul cluster di destinazione utilizzano lo stesso volume remoto utilizzato dal cluster di origine.
10. Cliccare su Next.

11. Selezionare un metodo di copia per ogni PV:

    • Lacopia degli snapshot esegue il backup e il ripristino dei dati utilizzando la funzionalità di snapshot del provider cloud. È significativamente più veloce della copia del file system.

    • Lacopia del file system esegue il backup dei file sul cluster di origine e li ripristina sul cluster di destinazione.

      Il metodo di copia del file system è richiesto per la migrazione diretta dei volumi.

12. È possibile selezionare Verify copy per verificare i dati migrati con la copia del file system. I dati sono verificati generando un checksum per ogni file di origine e controllando il checksum dopo il ripristino. La verifica dei dati riduce significativamente le prestazioni.

13. Selezionare una classe di storage di destinazione.

    Se è selezionata la copia del file system, è possibile cambiare la classe di storage di destinazione.

14. Cliccare su Next.

15. Nella pagina Migration options, è selezionata l'opzione Direct image migration se si è specificato un percorso esposto del registro delle immagini per il cluster di origine. L'opzione Direct PV migration è selezionata se si esegue la migrazione dei dati con la copia del file system.

    Le opzioni di migrazione diretta copiano immagini e file direttamente dal cluster di origine al cluster di destinazione. Questa opzione è molto più veloce che copiare immagini e file dal cluster di origine al repository di replica e poi dal repository di replica al cluster di destinazione.

16. Cliccare su Next.

17. Facoltativo: cliccare su Add Hook per aggiungere un hook al piano di migrazione.

    Un hook esegue del codice personalizzato. È possibile aggiungere fino a quattro hook a un singolo piano di migrazione. Ogni hook viene eseguito durante un diverso stadio della migrazione.

    1. Inserire il nome dell'hook da visualizzare nella console web.
    2. Se l'hook è un Ansible Playbook, selezionare Ansible Playbook e cliccare su Browse per caricare il playbook o incollare il contenuto del playbook nel campo.
    3. Facoltativo: specificare un'immagine di runtime di Ansible se non si utilizza l'immagine dell'hook predefinita.

    4. Se l'hook non è un Ansible Playbook, selezionare Custom container image e specificare il nome e il percorso dell'immagine.

       Un'immagine container personalizzata può includere degli Ansible Playbook.

    5. Selezionare il cluster di origine o il cluster di destinazione.
    6. Inserire il nome dell'account di servizio e lo spazio dei nomi dell'account di servizio.

    7. Selezionare lo stadio della migrazione per l'hook:

       • preBackup: prima che il carico di lavoro dell'applicazione sia sottoposto a backup sul cluster di origine
       • postBackup: dopo il backup del carico di lavoro dell'applicazione sul cluster di origine
       • preRestore: prima che il carico di lavoro dell'applicazione venga ripristinato sul cluster di destinazione
       • postRestore: dopo che il carico di lavoro dell'applicazione è stato ripristinato sul cluster di destinazione
    8. Cliccare su Add.

18. Cliccare su Finish.

    Il piano di migrazione viene visualizzato nell'elenco Migration plans.

Procedura

1. Accedere alla console web di MTC e cliccare su Migration plans.

2. Cliccare sul menu Opzioni accanto a un piano di migrazione e selezionare una delle seguenti opzioni sotto Migration:

   • La migrazione di fase copia i dati dal cluster di origine al cluster di destinazione senza fermare l'applicazione.

   • La migrazione completa ferma le transazioni sul cluster di origine e sposta le risorse sul cluster di destinazione.

     Facoltativo: nella finestra di dialogo della migrazione completa, è possibile deselezionare la casella di controllo Halt transactions on the source cluster during migration.

   • La migrazione dello stato copia le richieste di volumi permanenti (PVC) selezionate e le risorse Kubernetes che costituiscono lo stato di un'applicazione. È possibile usare la migrazione dello stato per eseguire la migrazione di uno spazio dei nomi all'interno dello stesso cluster.

     Importante

     Non utilizzare la migrazione dello stato per eseguire la migrazione di uno spazio dei nomi tra cluster. Usare invece la migrazione di fase o completa.

     • Selezionare una o più PVC nella finestra di dialogo State migration e cliccare su Migrate.

3. Quando la migrazione è stata completata, verificare che l'applicazione sia migrata con successo nella console web di OpenShift Container Platform:

   1. Cliccare su Home → Projects.
   2. Cliccare sul progetto migrato per visualizzarne lo stato.
   3. Nella sezione Routes, cliccare su Location per verificare che l'applicazione sia funzionante, se applicabile.
   4. Cliccare su Workloads → Pods per verificare che i pod siano in esecuzione nello spazio dei nomi migrato.
   5. Cliccare su Storage → Persistent volumes per verificare che il provisioning dei volumi permanenti migrati sia avvenuto correttamente.

Procedura

1. Ottenere il manifest della risorsa personalizzata MigrationController:

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

2. Aggiornare i parametri 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 proxy Stunnel per la migrazione diretta dei volumi.

   2

   URL proxy per creare connessioni HTTP all'esterno del cluster. Lo schema dell'URL deve essere http.

   3

   URL proxy per creare connessioni HTTPS all'esterno del cluster. Se questo non è specificato, allora viene utilizzato httpProxy per entrambe le connessioni HTTP e HTTPS.

   4

   Elenco separato da virgole di nomi di dominio di destinazione, domini, indirizzi IP o altri CIDR di rete per escludere il proxy.

   Precedere un dominio con . per far corrispondere solo i sottodomini. Ad esempio, .y.com corrisponde a x.y.com, ma non a y.com. Usare * per bypassare il proxy per tutte le destinazioni. Se si aumenta il numero di lavoratori che non sono inclusi nella rete definita dal campo networking.machineNetwork[].cidr della configurazione di installazione, è necessario aggiungerli a questa lista per prevenire problemi di connessione.

   Questo campo viene ignorato se non è impostato né il campo httpProxy né il campo httpsProxy.

3. Salvare il manifest come migration-controller.yaml.

4. Applicare il manifest aggiornato:

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

Procedura

1. Creare il manifest della risorsa personalizzata MigCluster per il cluster 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. Creare il manifest dell'oggetto Secret per ogni cluster 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

   Specificare il token dell'account di servizio (SA) migration-controller con codifica base64 del cluster remoto. È possibile ottenere il token eseguendo il seguente comando:

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

3. Creare il manifest della risorsa personalizzata MigCluster per ogni cluster 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

   Specificare la risorsa personalizzata Cluster del cluster remoto.

   2

   Facoltativo: per la migrazione diretta delle immagini, specificare il percorso del registro esposto.

   3

   La verifica SSL è abilitata se false. I certificati CA non sono richiesti o controllati se true.

   4

   Specificare l'oggetto Secret del cluster remoto.

   5

   Specificare l'URL del cluster remoto.

4. Verificare che tutti i cluster siano nello stato Ready:

   $ oc describe cluster <cluster>

5. Creare il manifest dell'oggetto Secret per il repository di replica:

   $ 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

   Specificare l'ID della chiave in formato base64.

   2

   Specificare la chiave segreta in formato base64.

   Le credenziali di AWS sono con codifica base64 per impostazione predefinita. Per gli altri provider di storage, è necessario codificare le proprie credenziali eseguendo il seguente comando con ogni chiave:

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

   1

   Specificare l'ID della chiave o la chiave segreta. Entrambe le chiavi devono essere con codifica base64.

6. Creare il manifest della risorsa personalizzata MigStorage per il repository di replica:

   $ 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

   Specificare il nome del bucket.

   2

   Specificare la risorsa personalizzata Secrets dello storage a oggetti. È necessario assicurarsi che le credenziali memorizzate nella risorsa personalizzata Secrets dello storage a oggetti siano corrette.

   3

   Specificare il provider di storage.

   4

   Facoltativo: se si copiano i dati usando gli snapshot, specificare la risorsa personalizzata Secrets dello storage a oggetti. È necessario assicurarsi che le credenziali memorizzate nella risorsa personalizzata Secrets dello storage a oggetti siano corrette.

   5

   Facoltativo: se si copiano i dati usando gli snapshot, specificare il provider di storage.

7. Verificare che la risorsa personalizzata MigStorage sia nello stato Ready:

   $ oc describe migstorage <migstorage>

8. Creare il manifest della risorsa personalizzata 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 migrazione diretta delle immagini è abilitata se false.

   2

   La migrazione diretta dei volumi è abilitata se false.

   3

   Specificare il nome dell'istanza della risorsa personalizzata MigStorage.

   4

   Specificare uno o più spazi dei nomi di origine. Per impostazione predefinita, lo spazio dei nomi di destinazione ha lo stesso nome.

   5

   Specificare uno spazio dei nomi di destinazione se è diverso dallo spazio dei nomi di origine.

   6

   Specificare il nome dell'istanza MigCluster del cluster di origine.

9. Verificare che l'istanza MigPlan sia nello stato Ready:

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

10. Creare il manifest della risorsa personalizzata MigMigration per avviare la migrazione definita nell'istanza 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

    Specificare il nome della risorsa personalizzata MigPlan.

    2

    I pod sul cluster di origine vengono fermati prima della migrazione, se true.

    3

    Una migrazione di fase, che copia la maggior parte dei dati senza fermare l'applicazione, viene eseguita se true.

    4

    Se true, una migrazione completata viene annullata.

11. Verificare la migrazione guardando il progresso della risorsa personalizzata MigMigration:

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

    L'output assomiglia al seguente:

    Esempio di output

    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

Procedura

1. Modificare il manifest delle risorse personalizzate di MigrationController:

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

2. Aggiornare la sezione spec aggiungendo un parametro per escludere risorse specifiche o aggiungendo una risorsa al parametro excluded_resources se non ha il proprio parametro di esclusione:

   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
     ...
     excluded_resources: 3
     - imagetags
     - templateinstances
     - clusterserviceversions
     - packagemanifests
     - subscriptions
     - servicebrokers
     - servicebindings
     - serviceclasses
     - serviceinstances
     - serviceplans
     - operatorgroups
     - events
     - events.events.k8s.io

   1

   Aggiungere disable_image_migration: true per escludere i flussi di immagini dalla migrazione. Non modificare il parametro excluded_resources. imagestreams viene aggiunto a excluded_resources quando il pod MigrationController si riavvia.

   2

   Aggiungere disable_pv_migration: true per escludere i PV dal piano di migrazione. Non modificare il parametro excluded_resources. persistentvolumes e persistentvolumeclaims sono aggiunti a excluded_resources quando il pod MigrationController si riavvia. Disabilitando la migrazione dei PV si disabilita anche il rilevamento dei PV quando si crea il piano di migrazione.

   3

   È possibile aggiungere le risorse di OpenShift Container Platform all'elenco excluded_resources. Non eliminare le risorse escluse predefinite. Queste risorse sono problematiche da migrare e devono essere escluse.

3. Attendere due minuti che il pod MigrationController si riavvii in modo che le modifiche siano applicate.

4. Verificare che la risorsa sia esclusa:

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

   L'output contiene le risorse escluse:

   Esempio di output

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

Procedura

1. Modificare il manifest della risorsa personalizzata MigrationController:

   $ oc edit migrationcontroller -n openshift-migration

2. Aggiornare i seguenti parametri:

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

   Specificare il numero di CPU disponibili per la risorsa personalizzata MigrationController.

   2

   Specificare la quantità di memoria disponibile nella risorsa personalizzata MigrationController.

   3

   Specificare il numero di unità CPU disponibili per le richieste della risorsa personalizzata MigrationController. 100m rappresenta 0,1 unità CPU (100 * 1e-3).

   4

   Specificare la quantità di memoria disponibile per le richieste della risorsa personalizzata MigrationController.

   5

   Specificare il numero di volumi permanenti che possono essere migrati.

   6

   Specificare il numero di pod che possono essere migrati.

   7

   Specificare il numero di spazi dei nomi che possono essere migrati.

3. Creare un piano di migrazione che utilizza i parametri aggiornati per verificare le modifiche.

   Se il piano di migrazione supera i limiti della risorsa personalizzata MigrationController, la console MTC mostra un messaggio di avvertimento quando si salva il piano di migrazione.

Procedura

1. Accedere al cluster dell'host.

2. Abilitare il ridimensionamento dei PV applicando una patch alla risorsa personalizzata MigrationController:

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

   1

   Impostare il valore su false per disabilitare il ridimensionamento dei PV.

3. Facoltativo: aggiornare il parametro pv_resizing_threshold per aumentare la soglia:

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

   1

   Il valore predefinito è 3.

   Quando la soglia viene superata, il seguente messaggio di stato viene visualizzato nello stato della risorsa personalizzata 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

   Per lo storage AWS gp2, questo messaggio non appare a meno che il valore pv_resizing_threshold non sia pari o superiore al 42% a causa del modo in cui gp2 calcola l'utilizzo e la dimensione del volume. (BZ#1973148)

Procedura

1. Abilitare i client nella cache eseguendo il seguente comando:

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

2. Facoltativo: aumentare i limiti di memoria della risorsa personalizzata MigrationController eseguendo il seguente comando:

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

3. Facoltativo: aumentare le richieste di memoria della risorsa personalizzata MigrationController eseguendo il seguente comando:

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

Procedura

1. Nella console web di MTC, cliccare su Migration Plans.
2. Cliccare sul numero Migrations accanto a un piano di migrazione per visualizzare la pagina Migrations.
3. Cliccare su una migrazione per visualizzare i dettagli della migrazione.

4. Espandere Migration resources per visualizzare le risorse di migrazione e il loro stato in una vista ad albero.

   Nota

   Per risolvere una migrazione non riuscita, iniziare con una risorsa di alto livello non riuscita e poi procedere lungo l'albero delle risorse verso le risorse di livello inferiore.

5. Cliccare sul menu Opzioni accanto a una risorsa e selezionare una delle seguenti opzioni:

   • L'opzione Copy oc describe command copia il comando negli appunti.

     • Accedere al cluster interessato e poi eseguire il comando.

       Le condizioni e gli eventi della risorsa sono visualizzati in formato YAML.

   • L'opzione Copy oc logs command copia il comando negli appunti.

     • Accedere al cluster interessato e poi eseguire il comando.

       Se la risorsa supporta il filtraggio dei registri, viene visualizzato un registro filtrato.

   • View JSON visualizza i dati della risorsa in formato JSON in un browser web.

     I dati sono gli stessi dell'output del comando oc get <resource>.

Procedura

1. Nella console web di MTC, cliccare su Migration Plans.
2. Cliccare sul numero di Migrations accanto a un piano di migrazione.
3. Cliccare su View logs.
4. Cliccare sull'icona Copy per copiare il comando oc logs negli appunti.

5. Accedere al cluster pertinente e inserire il comando nella CLI.

   Viene visualizzato il registro aggregato per il piano di migrazione.

Procedura

1. Ottenere il pod mig-log-reader:

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

2. Inserire il seguente comando per visualizzare un singolo registro di migrazione:

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

   1

   L'opzione -c plain mostra il registro senza colori.

Procedura

1. Nella console web di OpenShift Container Platform, cliccare su Observe → Metrics.

2. Inserire una query PromQL, selezionare una finestra temporale da visualizzare e cliccare su Run Queries.

   Se il browser web non mostra tutti i risultati, usare la console Prometheus.

Procedura

1. Andare alla directory dove si desidera memorizzare i dati must-gather.

2. Eseguire il comando oc adm must-gather per una delle seguenti opzioni di raccolta dati:

   • Per raccogliere i dati dell'ultima ora:

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

     I dati sono salvati come must-gather/must-gather.tar.gz. È possibile caricare questo file in un caso di supporto sul Red Hat Customer Portal.

   • Per raccogliere i dati delle ultime 24 ore:

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

     Questa operazione può richiedere molto tempo. I dati sono salvati come must-gather/metrics/prom_data.tar.gz.

Procedura

1. Decomprimere il file prom_data.tar.gz:

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

2. Creare un'istanza locale di Prometheus:

   $ make prometheus-run

   Il comando emette l'URL di Prometheus.

   Output

   Started Prometheus on http://localhost:9090

3. Avviare un browser web e andare all'URL per visualizzare i dati utilizzando la console web di Prometheus.

4. Dopo aver visualizzato i dati, eliminare l'istanza Prometheus e i dati:

   $ make prometheus-cleanup

Procedura

1. Controllare lo stato di una risorsa personalizzata MigMigration:

   $ oc get migmigration <migmigration> -o yaml

   Esempio di output

   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. Controllare lo stato della risorsa personalizzata Restore usando il comando Velero describe:

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

   Esempio di output

   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. Controllare i registri della risorsa personalizzata Restore usando il comando Velero logs:

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

   Esempio di output

   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

   Il messaggio di errore del registro della risorsa personalizzata Restore, the server could not find the requested resource, indica la causa della migrazione parzialmente non riuscita.

Procedura

1. Elencare le risorse personalizzate MigMigration nello spazio dei nomi openshift-migration:

   $ oc get migmigration -n openshift-migration

   Esempio di output

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

2. Ispezionare la risorsa personalizzata MigMigration:

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

   L'output è simile ai seguenti esempi.

Procedura

1. Assicurarsi che i registri interni siano esposti sui cluster OpenShift Container Platform 3 e 4.

   Il registro interno è esposto su OpenShift Container Platform 4 per impostazione predefinita.

2. Se si utilizzano registri insicuri, aggiungere i valori dell'host del registro alla sezione [registries.insecure] di /etc/container/registries.conf per assicurarsi che podman non incontri un errore di verifica TLS.

3. Accedere al registro di OpenShift Container Platform 3:

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

4. Accedere al registro di OpenShift Container Platform 4:

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

5. Eseguire pull dell'immagine di OpenShift Container Platform 3:

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

6. Etichettare l'immagine di OpenShift Container Platform 3 per il registro di OpenShift Container Platform 4:

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

   1

   Specificare l'URL del registro e la porta per il cluster di OpenShift Container Platform 3.

   2

   Specificare l'URL del registro e la porta per il cluster di OpenShift Container Platform 4.

7. Eseguire push dell'immagine nel registro di OpenShift Container Platform 4:

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

   1

   Specificare il cluster di OpenShift Container Platform 4.

8. Verificare che l'immagine abbia un flusso di immagini valido:

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

   Esempio di output

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

Procedura

1. Controllare lo stato della risorsa personalizzata MigMigration:

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

   L'output include il seguente messaggio di stato:

   Esempio di output

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

2. Sul cluster di origine, ottenere i dettagli di uno spazio dei nomi migrato:

   $ oc get namespace <namespace> -o yaml 1

   1

   Specificare lo spazio dei nomi migrato.

3. Sul cluster di destinazione, modificare lo spazio dei nomi migrato:

   $ oc edit namespace <namespace>

4. Aggiungere le annotazioni mancanti openshift.io/node-selector allo spazio dei nomi migrato come nell'esempio seguente:

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

5. Eseguire di nuovo il piano di migrazione.

Procedura

1. Nella console web di MTC, cliccare su Migration plans.
2. Cliccare sul menu Opzioni accanto a un piano di migrazione e selezionare Rollback sotto Migration.

3. Cliccare su Rollback e attendere che il rollback sia completato.

   Nei dettagli del piano di migrazione, viene visualizzato Rollback succedeed.

4. Verificare che il rollback sia andato a buon fine nella console web di OpenShift Container Platform del cluster di origine:

   1. Cliccare su Home → Projects.
   2. Cliccare sul progetto migrato per visualizzarne lo stato.
   3. Nella sezione Routes, cliccare su Location per verificare che l'applicazione sia funzionante, se applicabile.
   4. Cliccare su Workloads → Pods per verificare che i pod siano in esecuzione nello spazio dei nomi migrato.
   5. Cliccare su Storage → Persistent volumes per verificare che il provisioning del volume permanente migrato sia stato effettuato correttamente.

Procedura

1. Creare una risorsa personalizzata MigMigration basata sul seguente esempio:

   $ 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

   Specificare il nome della risorsa personalizzata MigPlan associata.

2. Nella console web di MTC, verificare che le risorse del progetto migrato siano state rimosse dal cluster di destinazione.
3. Verificare che le risorse del progetto migrato siano presenti nel cluster di origine e che l'applicazione sia in esecuzione.

Procedura

1. Eliminare i pod stage su tutti i cluster:

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

   1

   Spazi dei nomi specificati nella risorsa personalizzata MigPlan.

2. Riattivare l'applicazione sul cluster di origine ridimensionando le repliche sul numero di pre-migrazione:

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

   L'annotazione migration.openshift.io/preQuiesceReplicas nella risorsa personalizzata Deployment mostra il numero di repliche pre-migrazione:

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

3. Verificare che i pod delle applicazioni siano in esecuzione sul cluster di origine:

   $ oc get pod -n <namespace>