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 backend 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 multi-step 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

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.