Kubernetes migrations

For all Kubernetes-based migrations, Mirantis recommends running MMT in a Pod rather than using the docker run deployment method. Migration scenarios in which this does not apply are limited to MSR 2.9.x source systems and Swarm-based MSR 3.1.x source and target systems.

Important

• All Kubernetes-based migrations that use a filesystem back end must run MMT in a Pod.

• When performing a restore from within the MMT Pod, the Persistent Volume Claim (PVC) used by the Pod must contain the data extracted from the source MSR system.

Before you perform the migration, deploy the following Pod onto your Kubernetes-based source and target systems:

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: 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: mmt-pvc
  containers:
    - name: mmt
      image: registry.mirantis.com/msr/mmt:2.0.1
      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

Note

• In the rules section of the Role definition, add or remove permissions according to your requirements.

• For the PersistentVolumeClaim definition, modify the the spec.resources.storage value according to your requirements.

• In the Pod definition, the spec.volumes[0].persistentVolumeClaim.claimName field refers to the PVC used by the target MSR 3.x system. Modify the value as required.

• For the ClusterRoleBinding definition, the subjects.namespace field must refer to your MSR namespace. Modify the value as required.