Kubernetes migration

Available since MMT 2.0.3

In a streamlined Kubernetes migration, you run the migrate command, which accomplishes the migration in a small number of steps

Perform migration

The migration operation differs, depending on whether you are running it on a Persistent Volumes (PVs) storage system or a Filesystem storage system.

A migration performed on a PVs storage system requires that you run the migrate command within the Pod only.

To migrate an MSR system in Kubernetes mode for such storage options as AWS S3, Google Cloud, and Azure, run:

docker run -it --rm \
-v ~/.kube:/root/.kube \
-v <MSR 2.9x registry volume name>:/storage \
-v <migration dir>::/migration \
-v /var/run/docker.sock:/var/run/docker.sock \
msr.ci.mirantis.com/msr/mmt migrate /migration \
--storage-mode copy \
--parallel-io-count 1 \
--source-mke-url <MKE url> \
--source-url <MSR 2.9x url> \
--source-username <MRS admin username> \
--source-password <MSR admin password>
Command line parameters

Parameter

Description

storage-mode

Sets the registry migration storage mode.

Valid values: inplace, copy

parallel-io-count

Optional. Sets the number of parallel IO copies when performing blob storage copy tasks.

Default: 4

source-mke-url

Sets the URL for the source Mirantis Kubernetes Engine (MKE) system.

source-url

Sets the URL for the source MSR system.

source-username

Sets the username of the admin user. For MSR 2.9.x source systems, use the MKE admin user.

source-password

Sets the password of the admin user. For MSR 2.9.x source systems, use the MKE admin user.

Example output:

Successfully restored metadata from: "/home/<user-directory>/tmp/migrate/msr-backup-<MSR-version>-mmt.tar"

A migration performed on a filesystem storage requires that you run the migrate command twice, once within the Docker container, and then again within the deployed Pod.

  1. Run the migrate command within the Docker container:

    docker run -it --rm \
    -v <kubernets client configuration directory>:/root/.kube\
    -v <MSR 2.9x registry volume name>:/storage \
    -v <migration dir>:/migration \
    -v /var/run/docker.sock:/var/run/docker.sock \
    msr.ci.mirantis.com/msr/mmt \
    migrate /migration \
    --storage-mode copy \
    --parallel-io-count 1 \
    --source-mke-url <mke-url> \
    --source-url <msr-url> \
    --source-username <MRS admin username> \
    --source-password <MSR admin password>
    
    Command line parameters

    Parameter

    Description

    storage-mode

    Sets the registry migration storage mode.

    Valid values: inplace, copy

    parallel-io-count

    Optional. Sets the number of parallel IO copies when performing blob storage copy tasks.

    Default: 4

    source-mke-url

    Sets the URL for the source Mirantis Kubernetes Engine (MKE) system.

    source-url

    Sets the URL for the source MSR system.

    source-username

    Sets the username of the admin user. For MSR 2.9.x source systems, use the MKE admin user.

    source-password

    Sets the password of the admin user. For MSR 2.9.x source systems, use the MKE admin user.

    Example output:

    INFO[0025] Migration step one complete. Refer to the documentation for instructions on how to complete the second step of migration.
    
  2. Deploy the MMT Pod with the kubectl apply -f, using the provided YAML configuration.

    Modify, as required:

    • The permissions in the rules section of the Role directive.

    • The spec.resources.storage value in the PersistentVolumeClaim directive.

    • The spec.volumes[0].persistentVolumeClaim.claimName value in the Pod directive, which refers to the PVC in use by the target MSR 3.x system.

    • The subjects.namespace value in the ClusterRoleBinding directive, which must refer to your MSR namespace.

  3. Ensure the migration directory used in step 1 is accessible to the MMT Pod.

    The Pod YAML configuration file snippet below shows how the migration directory in use by the Docker command is mounted into the MMT Pod, from where the directory can be read:

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: migration
    spec:
      capacity:
        storage: 100Gi
      volumeMode: Filesystem
      accessModes:
      - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      storageClassName: mmt-migration
      hostPath:
        path: <migration directory>
        type: Directory
    ---
    
  4. Execute the migrate command on the target MSR system to restore your data:

    kubectl exec -it mmt /mmt migrate /migration --storage-mode copy --parallel-io-count 1  --source-mke-url <source mke url> --source-url <source msr url> --source-username <source msr admin user> --source-password <source msr password>
    
    Command line parameters

    Parameter

    Description

    parallel-io-count

    Optional. Sets the number of parallel IO copies when performing blob storage copy tasks.

    Default: 4

    source-mke-url

    Sets the URL for the source Mirantis Kubernetes Engine (MKE) system.

    source-url

    Sets the URL for the source MSR system.

    source-username

    Sets the username of the admin user. For MSR 2.9.x source systems, use the MKE admin user.

    source-password

    Sets the password of the admin user. For MSR 2.9.x source systems, use the MKE admin user.

    Example output:

    Successfully restored metadata from: "/home/<user-directory>/tmp/migrate/msr-backup-<MSR-version>-mmt.tar"
    

Perform post-restore eNZi registration

The process by which you register eNZi differs, depending on whether your system installation was performed through MSR Operator or a Helm chart

The MSR Operator automates the eNZi registration step. You must, however, manually restart the affected Pods:

for each in $(kubectl get deployments.apps -l "app.kubernetes.io/instance=msr" | tail -n+2 | cut -d ' ' -f1); do kubectl rollout restart $each; done

Note

In rare cases, the Pods may restart before the eNZi registration completes. If you are unable to log in to MSR, re-run the above command.

  1. Register MSR with eNZi:

    kubectl exec -it deployment/<msr-instance-name>-api -- \
    msr auth register \
    --username <username> \
    --password <password> \
    https://<msr-instance-name>-enzi:4443/enzi
    
  2. Restart the affected MSR Pods:

    for each in $(kubectl get deployments.apps -l "app.kubernetes.io/instance=msr" | tail -n+2 | cut -d ' ' -f1); do kubectl rollout restart $each; done