Add and configure OADP on your hosted cluster

Now that we've set up our original cluster with all the things we need, it's time to ensure our target cluster is appropriately configured. This will largely be a repeat of some of the steps we did earlier, but there are a few key differences to be aware of. 

Prerequisites:

• Administrator access to your destination cluster.
• Access to the same S3 buckets that hold any backups you make from your source cluster.
• Access to OpenShift APIs for Data Protection (OADP).

In this lesson, you will:

• Install OADP on your target hosted cluster.
• Configure the hosted cluster with appropriate secrets and settings. 

Installing OADP

To begin, we’ll install OADP directly on the hosted cluster where you want to restore the application. This can be done via the command-line interface (CLI) or console. 

Using the CLI

1. Start by inputting this command:

   export KUBECONFIG=~/kubeconfig-bm-hosted-cluster

2. Create the OADP namespace:

   cat <<EOF | oc apply -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-adp
   EOF

3. Create an OperatorGroup.

   cat <<EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: oadp-operator-group
     namespace: openshift-adp
   spec:
     targetNamespaces:
     - openshift-adp
   EOF

4. Create a Subscription with the following:

   cat <<EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: oadp-operator
     namespace: openshift-adp
   spec:
     channel: stable
     name: oadp-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     installPlanApproval: Automatic
   EOF

Using the console

1. Log in to the hosted cluster web console.
2. Click Operators → OperatorHub.
3. Search for OADP Operator in the search field.
4. Select the OADP Operator and click Install.
5. On the Install Operator page, adjust these settings:
   1. Update Channel: stable
   2. Installation Mode: A specific namespace on the cluster
   3. Installed Namespace: openshift-adp (create if it doesn't exist)
   4. Approval Strategy: Automatic
6. Click Install.

After these steps, double-check to verify the operator was installed correctly by doing the following:

1. Wait for the operator to be ready:

   oc wait --for=condition=ready pod -l control-plane=controller-manager \
     -n openshift-adp --timeout=300s

2. Verify OADP operator version:

   oc get csv -n openshift-adp | grep oadp-operator

   Expected output:

   oadp-operator.v1.5.5    OADP Operator    1.5.5    oadp-operator.v1.5.4    Succeeded

Configuring OADP on your hosted cluster

Now we’ll proceed through the process of getting OADP configured correctly, but this time on the hosted cluster where our backup will be moved to. 

1. Start by creating the same S3 credentials on the hosted cluster using:

   export KUBECONFIG=~/kubeconfig-bm-hosted-cluster

2. Create a credentials file:

   cat > /tmp/credentials-velero <<EOF
   [default]
   aws_access_key_id=<AWS_ACCESS_KEY_ID>
   aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
   EOF

3. Next, create a secret:

   oc create secret generic cloud-credentials \
     -n openshift-adp \
     --from-file cloud=/tmp/credentials-velero

4. Finally, clean up the credentials file with the following:

   rm /tmp/credentials-velero

5. Next, we’ll configure OADP to use the same S3 bucket as the source cluster. 

cat <<EOF | oc apply -f -
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-hosted control planes
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - openshift
        - aws
      resourceTimeout: 10m
    nodeAgent:
      enable: true
      uploaderType: kopia
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: cert-discovery-management-app
          prefix: management-export
        config:
          region: eu-north-1
          profile: "default"
        credential:
          name: cloud-credentials
          key: cloud
EOF

6. In this configuration, the key items to look out for are:

   • Same S3 bucket: Uses the same bucket as the source cluster backup.
   • Same prefix: management-export matches the source cluster configuration.
   • No HyperShift plugin: Not needed for workload restore.

7. Wait for the DataProtectionApplication (DPA) to reconcile.

   oc wait --for=condition=Reconciled dpa/velero-hosted control planes -n openshift-adp --timeout=300s

8. Check that all OADP pods are running.

   oc get pods -n openshift-adp

   Expected output:

   NAME                                                READY   STATUS    RESTARTS   AGE
   node-agent-xxxxx                                    1/1     Running   0          60s
   node-agent-yyyyy                                    1/1     Running   0          60s
   openshift-adp-controller-manager-xxxxx              1/1     Running   0          3m
   velero-xxxxx                                        1/1     Running

10. OADP should automatically discover existing backups from the S3 bucket. This can be started by using the following command to list all available backups:

    oc get backups -n openshift-adp

    Expected output:

    NAME                          AGE
    cert-discovery-app-backup     15m

11. Verify backup storage location is available:

    oc get backupstoragelocation -n openshift-adp

    Expected output:

    NAME      PHASE       LAST VALIDATED   AGE   DEFAULT
    default   Available   10s              75s   true

Apply cluster-scoped, role-based access controls

The ClusterRole and ClusterRoleBinding are cluster-scoped resources that were not included in the namespace backup. It’s important to apply these before restoring, so the application pods have permissions when they start.

1. Apply the YAML files you exported in the Prerequisites section.

   export KUBECONFIG=~/kubeconfig-bm-hosted-cluster

2. Clean up the exported YAML files (remove cluster-specific metadata) and remove these fields: resourceVersion, uid, creationTimestamp, managedFields.

   sed -i '' '/resourceVersion:/d; /uid:/d; /creationTimestamp:/d; /managedFields:/,/^[^ ]/d' /tmp/clusterrole-cert-discovery.yaml
   sed -i '' '/resourceVersion:/d; /uid:/d; /creationTimestamp:/d; /managedFields:/,/^[^ ]/d' /tmp/clusterrolebinding-cert-discovery.yaml

3. Apply the ClusterRole:

   oc apply -f /tmp/clusterrole-cert-discovery.yaml

4. Apply the ClusterRoleBinding:

   oc apply -f /tmp/clusterrolebinding-cert-discovery.yaml

5. Verify ClusterRole exists:

   oc get clusterrole cert-discovery-role

6. Verify ClusterRoleBinding exists:

   oc get clusterrolebinding cert-discovery-binding

7. Verify the ServiceAccount is bound correctly:

   oc describe clusterrolebinding cert-discovery-binding

   Expected output:

   Name:         cert-discovery-binding
   Role:
     Kind:  ClusterRole
     Name:  cert-discovery-role
   Subjects:
     Kind            Name               Namespace
     ----            ----               ---------
     ServiceAccount  cert-discovery-sa  cert-discovery-app

With all of the above handled, we’re ready to get our application off our old bare metal node and onto the hosted cluster.