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.

Persistent Volumes (PVs) storage

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 \
registry.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"

Filesystem storage

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.

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

Deploy the MMT Pod with the kubectl apply -f, using the provided YAML configuration.

Pod configuration

apiVersion: v1
kind: ServiceAccount
metadata:
  name: mmt-serviceaccount
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: mmt-role
rules:
  - apiGroups: ["", "apps", "rbac.authorization.k8s.io", "cert-manager.io", "acid.zalan.do"]
    resources: ["*"]
    verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: mmt-rolebinding
subjects:
  - kind: ServiceAccount
    name: mmt-serviceaccount
roleRef:
  kind: Role
  name: mmt-role
  apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: mmt-clusterrole
rules:
  # Add/remove more permissions as needed
  - apiGroups: ["", "msr.mirantis.com", "rethinkdb.com", "apiextensions.k8s.io"]
    resources: ["msrs", "rethinkdbs", "customresourcedefinitions", "persistentvolumes"]
    verbs: ["*"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: mmt-clusterrolebinding
subjects:
  - kind: ServiceAccount
    name: mmt-serviceaccount
    # Change this to the correct namespace.
    namespace: default
roleRef:
  kind: ClusterRole
  name: mmt-clusterrole
  apiGroup: rbac.authorization.k8s.io
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mmt-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: "20Gi"
---
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
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: migration-pvc
  namespace: default
spec:
  storageClassName: mmt-migration
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: mmt
spec:
  serviceAccountName: mmt-serviceaccount
  volumes:
    - name: storage
      persistentVolumeClaim:
        claimName: msr # #Locate the appropriate PVC using the kubectl get pvc command and replace as necessary.
    - name: migration
      persistentVolumeClaim:
        claimName: migration-pvc
  containers:
    - name: mmt
      image: registry.mirantis.com/msr/mmt:latest
      imagePullPolicy: IfNotPresent
      command: ["sh", "-c", "tail -f /dev/null"]
      volumeMounts:
      - name: storage
        mountPath: /storage
      - name: migration
        mountPath: /migration
      resources:
        limits:
          cpu: 500m
          memory: 256Mi
        requests:
          cpu: 100m
          memory: 256Mi
  restartPolicy: Never

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.

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

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

MSR Operator

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 deployment/$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.

Helm

kubectl exec -it deployment/<msr-instance-name>-api -- \
msr auth register \
--username <username> \
--password <password> \
https://<msr-instance-name>-enzi:4443/enzi

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 deployment/$each; done