Backup, restore, and disaster recovery for hosted control planes

If you need to back up and restore etcd on a hosted cluster or provide disaster recovery for a hosted cluster, see the following procedures.

Recovering etcd pods for hosted clusters

In hosted clusters, etcd pods run as part of a stateful set. The stateful set relies on persistent storage to store etcd data for each member. In a highly available control plane, the size of the stateful set is three pods, and each member has its own persistent volume claim.

Checking the status of a hosted cluster

To check the status of your hosted cluster, complete the following steps.

Procedure

  1. Enter the running etcd pod that you want to check by entering the following command:

    1. $ oc rsh -n <control_plane_namespace> -c etcd etcd-0

  2. Set up the etcdctl environment by entering the following commands:

    1. sh-4.4$ export ETCDCTL_API=3
    1. sh-4.4$ export ETCDCTL_CACERT=/etc/etcd/tls/etcd-ca/ca.crt
    1. sh-4.4$ export ETCDCTL_CERT=/etc/etcd/tls/client/etcd-client.crt
    1. sh-4.4$ export ETCDCTL_KEY=/etc/etcd/tls/client/etcd-client.key
    1. sh-4.4$ export ETCDCTL_ENDPOINTS=https://etcd-client:2379

  3. Print the endpoint status for each cluster member by entering the following command:

    1. sh-4.4$ etcdctl endpoint health --cluster -w table

Recovering an etcd member for a hosted cluster

An etcd member of a 3-node cluster might fail because of corrupted or missing data. To recover the etcd member, complete the following steps.

Procedure

  1. If you need to confirm that the etcd member is failing, enter the following command:

    1. $ oc get pods -l app=etcd -n <control_plane_namespace>

    The output resembles this example if the etcd member is failing:

    Example output

    1. NAME     READY   STATUS             RESTARTS     AGE
    2. etcd-0   2/2     Running            0            64m
    3. etcd-1   2/2     Running            0            45m
    4. etcd-2   1/2     CrashLoopBackOff   1 (5s ago)   64m

  2. Delete the persistent volume claim of the failing etcd member and the pod by entering the following command:

    1. $ oc delete pvc/data-etcd-2 pod/etcd-2 --wait=false

  3. When the pod restarts, verify that the etcd member is added back to the etcd cluster and is correctly functioning by entering the following command:

    1. $ oc get pods -l app=etcd -n $CONTROL_PLANE_NAMESPACE

    Example output

    1. NAME     READY   STATUS    RESTARTS   AGE
    2. etcd-0   2/2     Running   0          67m
    3. etcd-1   2/2     Running   0          48m
    4. etcd-2   2/2     Running   0          2m2s

Recovering an etcd cluster from a quorum loss

If multiple members of the etcd cluster have lost data or return a CrashLoopBackOff status, it can cause an etcd quorum loss. You must restore your etcd cluster from a snapshot.

This procedure requires API downtime.

Prerequisites

  • The oc and jq binaries have been installed.

Procedure

  1. First, set up your environment variables and scale down the API servers:

    1. Set up environment variables for your hosted cluster by entering the following commands, replacing values as necessary:

      1. $ CLUSTER_NAME=my-cluster
      1. $ HOSTED_CLUSTER_NAMESPACE=clusters
      1. $ CONTROL_PLANE_NAMESPACE="${HOSTED_CLUSTER_NAMESPACE}-${CLUSTER_NAME}"

    2. Pause reconciliation of the hosted cluster by entering the following command, replacing values as necessary:

      1. $ oc patch -n ${HOSTED_CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} -p '{"spec":{"pausedUntil":"true"}}' --type=merge

    3. Scale down the API servers by entering the following commands:

      1. Scale down the kube-apiserver:

        1. $ oc scale -n ${CONTROL_PLANE_NAMESPACE} deployment/kube-apiserver --replicas=0

      2. Scale down the openshift-apiserver:

        1. $ oc scale -n ${CONTROL_PLANE_NAMESPACE} deployment/openshift-apiserver --replicas=0

      3. Scale down the openshift-oauth-apiserver:

        1. $ oc scale -n ${CONTROL_PLANE_NAMESPACE} deployment/openshift-oauth-apiserver --replicas=0

  1. Next, take a snapshot of etcd by using one of the following methods:

    1. Use a previously backed-up snapshot of etcd.

    2. If you have an available etcd pod, take a snapshot from the active etcd pod by completing the following steps:

      1. List etcd pods by entering the following command:

        1. $ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd

      2. Take a snapshot of the pod database and save it locally to your machine by entering the following commands:

        1. $ ETCD_POD=etcd-0
        1. $ oc exec -n ${CONTROL_PLANE_NAMESPACE} -c etcd -t ${ETCD_POD} -- env ETCDCTL_API=3 /usr/bin/etcdctl \
        2. --cacert /etc/etcd/tls/etcd-ca/ca.crt \
        3. --cert /etc/etcd/tls/client/etcd-client.crt \
        4. --key /etc/etcd/tls/client/etcd-client.key \
        5. --endpoints=https://localhost:2379 \
        6. snapshot save /var/lib/snapshot.db

      3. Verify that the snapshot is successful by entering the following command:

        1. $ oc exec -n ${CONTROL_PLANE_NAMESPACE} -c etcd -t ${ETCD_POD} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/snapshot.db

    3. Make a local copy of the snapshot by entering the following command:

      1. $ oc cp -c etcd ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/snapshot.db /tmp/etcd.snapshot.db

      1. Make a copy of the snapshot database from etcd persistent storage:

        1. List etcd pods by entering the following command:

          1. $ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd

        2. Find a pod that is running and set its name as the value of ETCD_POD: ETCD_POD=etcd-0, and then copy its snapshot database by entering the following command:

          1. $ oc cp -c etcd ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/data/member/snap/db /tmp/etcd.snapshot.db

  1. Next, scale down the etcd statefulset by entering the following command:

    1. $ oc scale -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd --replicas=0

    1. Delete volumes for second and third members by entering the following command:

      1. $ oc delete -n ${CONTROL_PLANE_NAMESPACE} pvc/data-etcd-1 pvc/data-etcd-2

    2. Create a pod to access the first etcd member’s data:

      1. Get the etcd image by entering the following command:

        1. $ ETCD_IMAGE=$(oc get -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd -o jsonpath='{ .spec.template.spec.containers[0].image }')

      2. Create a pod that allows access to etcd data:

        1. $ cat << EOF | oc apply -n ${CONTROL_PLANE_NAMESPACE} -f -
        2. apiVersion: apps/v1
        3. kind: Deployment
        4. metadata:
        5.   name: etcd-data
        6. spec:
        7.   replicas: 1
        8.   selector:
        9.     matchLabels:
        10.       app: etcd-data
        11.   template:
        12.     metadata:
        13.       labels:
        14.         app: etcd-data
        15.     spec:
        16.       containers:
        17.       - name: access
        18.         image: $ETCD_IMAGE
        19.         volumeMounts:
        20.         - name: data
        21.           mountPath: /var/lib
        22.         command:
        23.         - /usr/bin/bash
        24.         args:
        25.         - -c
        26.         - |-
        27.           while true; do
        28.             sleep 1000
        29.           done
        30.       volumes:
        31.       - name: data
        32.         persistentVolumeClaim:
        33.           claimName: data-etcd-0
        34. EOF

      3. Check the status of the etcd-data pod and wait for it to be running by entering the following command:

        1. $ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd-data

      4. Get the name of the etcd-data pod by entering the following command:

        1. $ DATA_POD=$(oc get -n ${CONTROL_PLANE_NAMESPACE} pods --no-headers -l app=etcd-data -o name | cut -d/ -f2)

    3. Copy an etcd snapshot into the pod by entering the following command:

      1. $ oc cp /tmp/etcd.snapshot.db ${CONTROL_PLANE_NAMESPACE}/${DATA_POD}:/var/lib/restored.snap.db

    4. Remove old data from the etcd-data pod by entering the following commands:

      1. $ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- rm -rf /var/lib/data
      1. $ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- mkdir -p /var/lib/data

    5. Restore the etcd snapshot by entering the following command:

      1. $ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- etcdutl snapshot restore /var/lib/restored.snap.db \
      2.      --data-dir=/var/lib/data --skip-hash-check \
      3.      --name etcd-0 \
      4.      --initial-cluster-token=etcd-cluster \
      5.      --initial-cluster etcd-0=https://etcd-0.etcd-discovery.${CONTROL_PLANE_NAMESPACE}.svc:2380,etcd-1=https://etcd-1.etcd-discovery.${CONTROL_PLANE_NAMESPACE}.svc:2380,etcd-2=https://etcd-2.etcd-discovery.${CONTROL_PLANE_NAMESPACE}.svc:2380 \
      6.      --initial-advertise-peer-urls https://etcd-0.etcd-discovery.${CONTROL_PLANE_NAMESPACE}.svc:2380

    6. Remove the temporary etcd snapshot from the pod by entering the following command:

      1. $ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- rm /var/lib/restored.snap.db

    7. Delete data access deployment by entering the following command:

      1. $ oc delete -n ${CONTROL_PLANE_NAMESPACE} deployment/etcd-data

    8. Scale up the etcd cluster by entering the following command:

      1. $ oc scale -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd --replicas=3

    9. Wait for the etcd member pods to return and report as available by entering the following command:

      1. $ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd -w

    10. Scale up all etcd-writer deployments by entering the following command:

      1. $ oc scale deployment -n ${CONTROL_PLANE_NAMESPACE} --replicas=3 kube-apiserver openshift-apiserver openshift-oauth-apiserver

  2. Restore reconciliation of the hosted cluster by entering the following command:

    1. $ oc patch -n ${CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} -p '{"spec":{"pausedUntil":""}}' --type=merge

Backing up and restoring etcd on a hosted cluster on AWS

If you use hosted control planes for OKD, the process to back up and restore etcd is different from the usual etcd backup process.

The following procedures are specific to hosted control planes on AWS.

Hosted control planes on the AWS platform is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Taking a snapshot of etcd on a hosted cluster

As part of the process to back up etcd for a hosted cluster, you take a snapshot of etcd. After you take the snapshot, you can restore it, for example, as part of a disaster recovery operation.

This procedure requires API downtime.

Procedure

  1. Pause reconciliation of the hosted cluster by entering this command:

    1. $ oc patch -n clusters hostedclusters/${CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge

  2. Stop all etcd-writer deployments by entering this command:

    1. $ oc scale deployment -n ${HOSTED_CLUSTER_NAMESPACE} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver

  3. Take an etcd snapshot by using the exec command in each etcd container:

    1. $ oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/client/etcd-client-ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db
    2. $ oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.db

  4. Copy the snapshot data to a location where you can retrieve it later, such as an S3 bucket, as shown in the following example.

    The following example uses signature version 2. If you are in a region that supports signature version 4, such as the us-east-2 region, use signature version 4. Otherwise, if you use signature version 2 to copy the snapshot to an S3 bucket, the upload fails and signature version 2 is deprecated.

    Example

    1. BUCKET_NAME=somebucket
    2. FILEPATH="/${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db"
    3. CONTENT_TYPE="application/x-compressed-tar"
    4. DATE_VALUE=`date -R`
    5. SIGNATURE_STRING="PUT\n\n${CONTENT_TYPE}\n${DATE_VALUE}\n${FILEPATH}"
    6. ACCESS_KEY=accesskey
    7. SECRET_KEY=secret
    8. SIGNATURE_HASH=`echo -en ${SIGNATURE_STRING} | openssl sha1 -hmac ${SECRET_KEY} -binary | base64`
    10. oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- curl -X PUT -T "/var/lib/data/snapshot.db" \
    11.   -H "Host: ${BUCKET_NAME}.s3.amazonaws.com" \
    12.   -H "Date: ${DATE_VALUE}" \
    13.   -H "Content-Type: ${CONTENT_TYPE}" \
    14.   -H "Authorization: AWS ${ACCESS_KEY}:${SIGNATURE_HASH}" \
    15.   https://${BUCKET_NAME}.s3.amazonaws.com/${CLUSTER_NAME}-snapshot.db

  5. If you want to be able to restore the snapshot on a new cluster later, save the encryption secret that the hosted cluster references, as shown in this example:

    Example

    1. oc get hostedcluster $CLUSTER_NAME -o=jsonpath='{.spec.secretEncryption.aescbc}'
    2. {"activeKey":{"name":"CLUSTER_NAME-etcd-encryption-key"}}
    4. # Save this secret, or the key it contains so the etcd data can later be decrypted
    5. oc get secret ${CLUSTER_NAME}-etcd-encryption-key -o=jsonpath='{.data.key}'

Next steps

Restore the etcd snapshot.

Restoring an etcd snapshot on a hosted cluster

If you have a snapshot of etcd from your hosted cluster, you can restore it. Currently, you can restore an etcd snapshot only during cluster creation.

To restore an etcd snapshot, you modify the output from the create cluster --render command and define a restoreSnapshotURL value in the etcd section of the HostedCluster specification.

Prerequisites

You took an etcd snapshot on a hosted cluster.

Procedure

  1. On the aws command-line interface (CLI), create a pre-signed URL so that you can download your etcd snapshot from S3 without passing credentials to the etcd deployment:

    1. ETCD_SNAPSHOT=${ETCD_SNAPSHOT:-"s3://${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db"}
    2. ETCD_SNAPSHOT_URL=$(aws s3 presign ${ETCD_SNAPSHOT})

  2. Modify the HostedCluster specification to refer to the URL:

    1. spec:
    2.   etcd:
    3.     managed:
    4.       storage:
    5.         persistentVolume:
    6.           size: 4Gi
    7.         type: PersistentVolume
    8.         restoreSnapshotURL:
    9.         - "${ETCD_SNAPSHOT_URL}"
    10.     managementType: Managed

  3. Ensure that the secret that you referenced from the spec.secretEncryption.aescbc value contains the same AES key that you saved in the previous steps.

Disaster recovery for a hosted cluster within an AWS region

In a situation where you need disaster recovery (DR) for a hosted cluster, you can recover a hosted cluster to the same region within AWS. For example, you need DR when the upgrade of a management cluster fails and the hosted cluster is in a read-only state.

Hosted control planes is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

The DR process involves three main steps:

  1. Backing up the hosted cluster on the source management cluster

  2. Restoring the hosted cluster on a destination management cluster

  3. Deleting the hosted cluster from the source management cluster

Your workloads remain running during the process. The Cluster API might be unavailable for a period, but that will not affect the services that are running on the worker nodes.

Both the source management cluster and the destination management cluster must have the —external-dns flags to maintain the API server URL, as shown in this example:

Example: External DNS flags
  1. —external-dns-provider=aws \
  2. —external-dns-credentials=<AWS Credentials location> \
  3. —external-dns-domain-filter=<DNS Base Domain>

If you do not include the —external-dns flags to maintain the API server URL, the hosted cluster cannot be migrated.

Example environment and context

Consider an scenario where you have three clusters to restore. Two are management clusters, and one is a hosted cluster. You can restore either the control plane only or the control plane and the nodes. Before you begin, you need the following information:

  • Source MGMT Namespace: The source management namespace

  • Source MGMT ClusterName: The source management cluster name

  • Source MGMT Kubeconfig: The source management kubeconfig file

  • Destination MGMT Kubeconfig: The destination management kubeconfig file

  • HC Kubeconfig: The hosted cluster kubeconfig file

  • SSH key file: The SSH public key

  • Pull secret: The pull secret file to access the release images

  • AWS credentials

  • AWS region

  • Base domain: The DNS base domain to use as an external DNS

  • S3 bucket name: The bucket in the AWS region where you plan to upload the etcd backup

This information is shown in the following example environment variables.

Example environment variables

  1. SSH_KEY_FILE=${HOME}/.ssh/id_rsa.pub
  2. BASE_PATH=${HOME}/hypershift
  3. BASE_DOMAIN="aws.sample.com"
  4. PULL_SECRET_FILE="${HOME}/pull_secret.json"
  5. AWS_CREDS="${HOME}/.aws/credentials"
  6. AWS_ZONE_ID="Z02718293M33QHDEQBROL"
  8. CONTROL_PLANE_AVAILABILITY_POLICY=SingleReplica
  9. HYPERSHIFT_PATH=${BASE_PATH}/src/hypershift
  10. HYPERSHIFT_CLI=${HYPERSHIFT_PATH}/bin/hypershift
  11. HYPERSHIFT_IMAGE=${HYPERSHIFT_IMAGE:-"quay.io/${USER}/hypershift:latest"}
  12. NODE_POOL_REPLICAS=${NODE_POOL_REPLICAS:-2}
  14. # MGMT Context
  15. MGMT_REGION=us-west-1
  16. MGMT_CLUSTER_NAME="${USER}-dev"
  17. MGMT_CLUSTER_NS=${USER}
  18. MGMT_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT_CLUSTER_NS}-${MGMT_CLUSTER_NAME}"
  19. MGMT_KUBECONFIG="${MGMT_CLUSTER_DIR}/kubeconfig"
  21. # MGMT2 Context
  22. MGMT2_CLUSTER_NAME="${USER}-dest"
  23. MGMT2_CLUSTER_NS=${USER}
  24. MGMT2_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT2_CLUSTER_NS}-${MGMT2_CLUSTER_NAME}"
  25. MGMT2_KUBECONFIG="${MGMT2_CLUSTER_DIR}/kubeconfig"
  27. # Hosted Cluster Context
  28. HC_CLUSTER_NS=clusters
  29. HC_REGION=us-west-1
  30. HC_CLUSTER_NAME="${USER}-hosted"
  31. HC_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}"
  32. HC_KUBECONFIG="${HC_CLUSTER_DIR}/kubeconfig"
  33. BACKUP_DIR=${HC_CLUSTER_DIR}/backup
  35. BUCKET_NAME="${USER}-hosted-${MGMT_REGION}"
  37. # DNS
  38. AWS_ZONE_ID="Z07342811SH9AA102K1AC"
  39. EXTERNAL_DNS_DOMAIN="hc.jpdv.aws.kerbeross.com"

Overview of the backup and restore process

The backup and restore process works as follows:

  1. On management cluster 1, which you can think of as the source management cluster, the control plane and workers interact by using the external DNS API. The external DNS API is accessible, and a load balancer sits between the management clusters.

    Diagram that shows the workers accessing the external DNS API and the external DNS API pointing to the control plane through a load balancer

  2. You take a snapshot of the hosted cluster, which includes etcd, the control plane, and the worker nodes. During this process, the worker nodes continue to try to access the external DNS API even if it is not accessible, the workloads are running, the control plane is saved in a local manifest file, and etcd is backed up to an S3 bucket. The data plane is active and the control plane is paused.

    298 OpenShift Backup Restore 0123 01

  3. On management cluster 2, which you can think of as the destination management cluster, you restore etcd from the S3 bucket and restore the control plane from the local manifest file. During this process, the external DNS API is stopped, the hosted cluster API becomes inaccessible, and any workers that use the API are unable to update their manifest files, but the workloads are still running.

    298 OpenShift Backup Restore 0123 02

  4. The external DNS API is accessible again, and the worker nodes use it to move to management cluster 2. The external DNS API can access the load balancer that points to the control plane.

    298 OpenShift Backup Restore 0123 03

  5. On management cluster 2, the control plane and worker nodes interact by using the external DNS API. The resources are deleted from management cluster 1, except for the S3 backup of etcd. If you try to set up the hosted cluster again on mangagement cluster 1, it will not work.

    298 OpenShift Backup Restore 0123 04

You can manually back up and restore your hosted cluster, or you can run a script to complete the process. For more information about the script, see “Running a script to back up and restore a hosted cluster”.

Backing up a hosted cluster

To recover your hosted cluster in your target management cluster, you first need to back up all of the relevant data.

Procedure

  1. Create a configmap file to declare the source management cluster by entering this command:

    1. $ oc create configmap mgmt-parent-cluster -n default --from-literal=from=${MGMT_CLUSTER_NAME}

  2. Shut down the reconciliation in the hosted cluster and in the node pools by entering these commands:

    1. PAUSED_UNTIL="true"
    2. oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
    3. oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator
    1. PAUSED_UNTIL="true"
    2. oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
    3. oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
    4. oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator

  3. Back up etcd and upload the data to an S3 bucket by running this bash script:

    Wrap this script in a function and call it from the main function.

    1. # ETCD Backup
    2. ETCD_PODS="etcd-0"
    3. if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then
    4.   ETCD_PODS="etcd-0 etcd-1 etcd-2"
    5. fi
    7. for POD in ${ETCD_PODS}; do
    8.   # Create an etcd snapshot
    9.   oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/client/etcd-client-ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db
    10.   oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.db
    12.   FILEPATH="/${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db"
    13.   CONTENT_TYPE="application/x-compressed-tar"
    14.   DATE_VALUE=`date -R`
    15.   SIGNATURE_STRING="PUT\n\n${CONTENT_TYPE}\n${DATE_VALUE}\n${FILEPATH}"
    17.   set +x
    18.   ACCESS_KEY=$(grep aws_access_key_id ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g")
    19.   SECRET_KEY=$(grep aws_secret_access_key ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g")
    20.   SIGNATURE_HASH=$(echo -en ${SIGNATURE_STRING} | openssl sha1 -hmac "${SECRET_KEY}" -binary | base64)
    21.   set -x
    23.   # FIXME: this is pushing to the OIDC bucket
    24.   oc exec -it etcd-0 -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- curl -X PUT -T "/var/lib/data/snapshot.db" \
    25.     -H "Host: ${BUCKET_NAME}.s3.amazonaws.com" \
    26.     -H "Date: ${DATE_VALUE}" \
    27.     -H "Content-Type: ${CONTENT_TYPE}" \
    28.     -H "Authorization: AWS ${ACCESS_KEY}:${SIGNATURE_HASH}" \
    29.     https://${BUCKET_NAME}.s3.amazonaws.com/${HC_CLUSTER_NAME}-${POD}-snapshot.db
    30. done

    For more information about backing up etcd, see “Backing up and restoring etcd on a hosted cluster”.

  4. Back up Kubernetes and OKD objects by entering the following commands. You need to back up the following objects:

    • HostedCluster and NodePool objects from the HostedCluster namespace

    • HostedCluster secrets from the HostedCluster namespace

    • HostedControlPlane from the Hosted Control Plane namespace

    • Cluster from the Hosted Control Plane namespace

    • AWSCluster, AWSMachineTemplate, and AWSMachine from the Hosted Control Plane namespace

    • MachineDeployments, MachineSets, and Machines from the Hosted Control Plane namespace

    • ControlPlane secrets from the Hosted Control Plane namespace

      1. mkdir -p ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS} ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
      2. chmod 700 ${BACKUP_DIR}/namespaces/
      4. # HostedCluster
      5. echo "Backing Up HostedCluster Objects:"
      6. oc get hc ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
      7. echo "--> HostedCluster"
      8. sed -i '' -e '/^status:$/,$d' ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
      10. # NodePool
      11. oc get np ${NODEPOOLS} -n ${HC_CLUSTER_NS} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml
      12. echo "--> NodePool"
      13. sed -i '' -e '/^status:$/,$ d' ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml
      15. # Secrets in the HC Namespace
      16. echo "--> HostedCluster Secrets:"
      17. for s in $(oc get secret -n ${HC_CLUSTER_NS} | grep "^${HC_CLUSTER_NAME}" | awk '{print $1}'); do
      18.     oc get secret -n ${HC_CLUSTER_NS} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-${s}.yaml
      19. done
      21. # Secrets in the HC Control Plane Namespace
      22. echo "--> HostedCluster ControlPlane Secrets:"
      23. for s in $(oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} | egrep -v "docker|service-account-token|oauth-openshift|NAME|token-${HC_CLUSTER_NAME}" | awk '{print $1}'); do
      24.     oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-${s}.yaml
      25. done
      27. # Hosted Control Plane
      28. echo "--> HostedControlPlane:"
      29. oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-${HC_CLUSTER_NAME}.yaml
      31. # Cluster
      32. echo "--> Cluster:"
      33. CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})
      34. oc get cluster ${CL_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-${HC_CLUSTER_NAME}.yaml
      36. # AWS Cluster
      37. echo "--> AWS Cluster:"
      38. oc get awscluster ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-${HC_CLUSTER_NAME}.yaml
      40. # AWS MachineTemplate
      41. echo "--> AWS Machine Template:"
      42. oc get awsmachinetemplate ${NODEPOOLS} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-${HC_CLUSTER_NAME}.yaml
      44. # AWS Machines
      45. echo "--> AWS Machine:"
      46. CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})
      47. for s in $(oc get awsmachines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --no-headers | grep ${CL_NAME} | cut -f1 -d\ ); do
      48.     oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} awsmachines $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-${s}.yaml
      49. done
      51. # MachineDeployments
      52. echo "--> HostedCluster MachineDeployments:"
      53. for s in $(oc get machinedeployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
      54.     mdp_name=$(echo ${s} | cut -f 2 -d /)
      55.     oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-${mdp_name}.yaml
      56. done
      58. # MachineSets
      59. echo "--> HostedCluster MachineSets:"
      60. for s in $(oc get machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
      61.     ms_name=$(echo ${s} | cut -f 2 -d /)
      62.     oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-${ms_name}.yaml
      63. done
      65. # Machines
      66. echo "--> HostedCluster Machine:"
      67. for s in $(oc get machine -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
      68.     m_name=$(echo ${s} | cut -f 2 -d /)
      69.     oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-${m_name}.yaml
      70. done

  5. Clean up the ControlPlane routes by entering this command:

    1. $ oc delete routes -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all

    By entering that command, you enable the ExternalDNS Operator to delete the Route53 entries.

  6. Verify that the Route53 entries are clean by running this script:

    1. function clean_routes() {
    3.     if [[ -z "${1}" ]];then
    4.         echo "Give me the NS where to clean the routes"
    5.         exit 1
    6.     fi
    8.     # Constants
    9.     if [[ -z "${2}" ]];then
    10.         echo "Give me the Route53 zone ID"
    11.         exit 1
    12.     fi
    14.     ZONE_ID=${2}
    15.     ROUTES=10
    16.     timeout=40
    17.     count=0
    19.     # This allows us to remove the ownership in the AWS for the API route
    20.     oc delete route -n ${1} --all
    22.     while [ ${ROUTES} -gt 2 ]
    23.     do
    24.         echo "Waiting for ExternalDNS Operator to clean the DNS Records in AWS Route53 where the zone id is: ${ZONE_ID}..."
    25.         echo "Try: (${count}/${timeout})"
    26.         sleep 10
    27.         if [[ $count -eq timeout ]];then
    28.             echo "Timeout waiting for cleaning the Route53 DNS records"
    29.             exit 1
    30.         fi
    31.         count=$((count+1))
    32.         ROUTES=$(aws route53 list-resource-record-sets --hosted-zone-id ${ZONE_ID} --max-items 10000 --output json | grep -c ${EXTERNAL_DNS_DOMAIN})
    33.     done
    34. }
    36. # SAMPLE: clean_routes "<HC ControlPlane Namespace>" "<AWS_ZONE_ID>"
    37. clean_routes "${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}" "${AWS_ZONE_ID}"

Verification

Check all of the OKD objects and the S3 bucket to verify that everything looks as expected.

Next steps

Restore your hosted cluster.

Restoring a hosted cluster

Gather all of the objects that you backed up and restore them in your destination management cluster.

Prerequisites

You backed up the data from your source management cluster.

Ensure that the kubeconfig file of the destination management cluster is placed as it is set in the KUBECONFIG variable or, if you use the script, in the MGMT2_KUBECONFIG variable. Use export KUBECONFIG=<Kubeconfig FilePath> or, if you use the script, use export KUBECONFIG=${MGMT2_KUBECONFIG}.

Procedure

  1. Verify that the new management cluster does not contain any namespaces from the cluster that you are restoring by entering these commands:

    1. # Just in case
    2. export KUBECONFIG=${MGMT2_KUBECONFIG}
    3. BACKUP_DIR=${HC_CLUSTER_DIR}/backup
    5. # Namespace deletion in the destination Management cluster
    6. $ oc delete ns ${HC_CLUSTER_NS} || true
    7. $ oc delete ns ${HC_CLUSTER_NS}-{HC_CLUSTER_NAME} || true

  2. Re-create the deleted namespaces by entering these commands:

    1. # Namespace creation
    2. $ oc new-project ${HC_CLUSTER_NS}
    3. $ oc new-project ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}

  3. Restore the secrets in the HC namespace by entering this command:

    1. $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-*

  4. Restore the objects in the HostedCluster control plane namespace by entering these commands:

    1. # Secrets
    2. $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-*
    4. # Cluster
    5. $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-*
    6. $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-*

  5. If you are recovering the nodes and the node pool to reuse AWS instances, restore the objects in the HC control plane namespace by entering these commands:

    1. # AWS
    2. $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-*
    3. $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-*
    4. $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-*
    6. # Machines
    7. $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-*
    8. $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-*
    9. $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-*

  6. Restore the etcd data and the hosted cluster by running this bash script:

    1. ETCD_PODS="etcd-0"
    2. if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then
    3.   ETCD_PODS="etcd-0 etcd-1 etcd-2"
    4. fi
    6. HC_RESTORE_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-restore.yaml
    7. HC_BACKUP_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
    8. HC_NEW_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-new.yaml
    9. cat ${HC_BACKUP_FILE} > ${HC_NEW_FILE}
    10. cat > ${HC_RESTORE_FILE} <<EOF
    11.     restoreSnapshotURL:
    12. EOF
    14. for POD in ${ETCD_PODS}; do
    15.   # Create a pre-signed URL for the etcd snapshot
    16.   ETCD_SNAPSHOT="s3://${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db"
    17.   ETCD_SNAPSHOT_URL=$(AWS_DEFAULT_REGION=${MGMT2_REGION} aws s3 presign ${ETCD_SNAPSHOT})
    19.   # FIXME no CLI support for restoreSnapshotURL yet
    20.   cat >> ${HC_RESTORE_FILE} <<EOF
    21.     - "${ETCD_SNAPSHOT_URL}"
    22. EOF
    23. done
    25. cat ${HC_RESTORE_FILE}
    27. if ! grep ${HC_CLUSTER_NAME}-snapshot.db ${HC_NEW_FILE}; then
    28.   sed -i '' -e "/type: PersistentVolume/r ${HC_RESTORE_FILE}" ${HC_NEW_FILE}
    29.   sed -i '' -e '/pausedUntil:/d' ${HC_NEW_FILE}
    30. fi
    32. HC=$(oc get hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME} -o name || true)
    33. if [[ ${HC} == "" ]];then
    34.     echo "Deploying HC Cluster: ${HC_CLUSTER_NAME} in ${HC_CLUSTER_NS} namespace"
    35.     oc apply -f ${HC_NEW_FILE}
    36. else
    37.     echo "HC Cluster ${HC_CLUSTER_NAME} already exists, avoiding step"
    38. fi

  7. If you are recovering the nodes and the node pool to reuse AWS instances, restore the node pool by entering this command:

    1. oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-*

Verification

  • To verify that the nodes are fully restored, use this function:

    1. timeout=40
    2. count=0
    3. NODE_STATUS=$(oc get nodes --kubeconfig=${HC_KUBECONFIG} | grep -v NotReady | grep -c "worker") || NODE_STATUS=0
    5. while [ ${NODE_POOL_REPLICAS} != ${NODE_STATUS} ]
    6. do
    7.     echo "Waiting for Nodes to be Ready in the destination MGMT Cluster: ${MGMT2_CLUSTER_NAME}"
    8.     echo "Try: (${count}/${timeout})"
    9.     sleep 30
    10.     if [[ $count -eq timeout ]];then
    11.         echo "Timeout waiting for Nodes in the destination MGMT Cluster"
    12.         exit 1
    13.     fi
    14.     count=$((count+1))
    15.     NODE_STATUS=$(oc get nodes --kubeconfig=${HC_KUBECONFIG} | grep -v NotReady | grep -c "worker") || NODE_STATUS=0
    16. done

Next steps

Shut down and delete your cluster.

Deleting a hosted cluster from your source management cluster

After you back up your hosted cluster and restore it to your destination management cluster, you shut down and delete the hosted cluster on your source management cluster.

Prerequisites

You backed up your data and restored it to your source management cluster.

Ensure that the kubeconfig file of the destination management cluster is placed as it is set in the KUBECONFIG variable or, if you use the script, in the MGMT_KUBECONFIG variable. Use export KUBECONFIG=<Kubeconfig FilePath> or, if you use the script, use export KUBECONFIG=${MGMT_KUBECONFIG}.

Procedure

  1. Scale the deployment and statefulset objects by entering these commands:

    Do not scale the stateful set if the value of its spec.persistentVolumeClaimRetentionPolicy.whenScaled field is set to Delete, because this could lead to a loss of data.

    As a workaround, update the value of the spec.persistentVolumeClaimRetentionPolicy.whenScaled field to Retain. Ensure that no controllers exist that reconcile the stateful set and would return the value back to Delete, which could lead to a loss of data.

    1. # Just in case
    2. export KUBECONFIG=${MGMT_KUBECONFIG}
    4. # Scale down deployments
    5. oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all
    6. oc scale statefulset.apps -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all
    7. sleep 15

  2. Delete the NodePool objects by entering these commands:

    1. NODEPOOLS=$(oc get nodepools -n ${HC_CLUSTER_NS} -o=jsonpath='{.items[?(@.spec.clusterName=="'${HC_CLUSTER_NAME}'")].metadata.name}')
    2. if [[ ! -z "${NODEPOOLS}" ]];then
    3.     oc patch -n "${HC_CLUSTER_NS}" nodepool ${NODEPOOLS} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
    4.     oc delete np -n ${HC_CLUSTER_NS} ${NODEPOOLS}
    5. fi

  3. Delete the machine and machineset objects by entering these commands:

    1. # Machines
    2. for m in $(oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
    3.     oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true
    4.     oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true
    5. done
    7. oc delete machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all || true

  4. Delete the cluster object by entering these commands:

    1. # Cluster
    2. C_NAME=$(oc get cluster -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)
    3. oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${C_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
    4. oc delete cluster.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all

  5. Delete the AWS machines (Kubernetes objects) by entering these commands. Do not worry about deleting the real AWS machines. The cloud instances will not be affected.

    1. # AWS Machines
    2. for m in $(oc get awsmachine.infrastructure.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)
    3. do
    4.     oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true
    5.     oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true
    6. done

  6. Delete the HostedControlPlane and ControlPlane HC namespace objects by entering these commands:

    1. # Delete HCP and ControlPlane HC NS
    2. oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} hostedcontrolplane.hypershift.openshift.io ${HC_CLUSTER_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
    3. oc delete hostedcontrolplane.hypershift.openshift.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all
    4. oc delete ns ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} || true

  7. Delete the HostedCluster and HC namespace objects by entering these commands:

    1. # Delete HC and HC Namespace
    2. oc -n ${HC_CLUSTER_NS} patch hostedclusters ${HC_CLUSTER_NAME} -p '{"metadata":{"finalizers":null}}' --type merge || true
    3. oc delete hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME}  || true
    4. oc delete ns ${HC_CLUSTER_NS} || true

Verification

  • To verify that everything works, enter these commands:

    1. # Validations
    2. export KUBECONFIG=${MGMT2_KUBECONFIG}
    4. oc get hc -n ${HC_CLUSTER_NS}
    5. oc get np -n ${HC_CLUSTER_NS}
    6. oc get pod -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
    7. oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
    9. # Inside the HostedCluster
    10. export KUBECONFIG=${HC_KUBECONFIG}
    11. oc get clusterversion
    12. oc get nodes

Next steps

Delete the OVN pods in the hosted cluster so that you can connect to the new OVN control plane that runs in the new management cluster:

  1. Load the KUBECONFIG environment variable with the hosted cluster’s kubeconfig path.

  2. Enter this command:

    1. $ oc delete pod -n openshift-ovn-kubernetes --all

Running a script to back up and restore a hosted cluster

To expedite the process to back up a hosted cluster and restore it within the same region on AWS, you can modify and run a script.

Procedure

  1. Replace the variables in the following script with your information:

    1. # Fill the Common variables to fit your environment, this is just a sample
    2. SSH_KEY_FILE=${HOME}/.ssh/id_rsa.pub
    3. BASE_PATH=${HOME}/hypershift
    4. BASE_DOMAIN="aws.sample.com"
    5. PULL_SECRET_FILE="${HOME}/pull_secret.json"
    6. AWS_CREDS="${HOME}/.aws/credentials"
    7. CONTROL_PLANE_AVAILABILITY_POLICY=SingleReplica
    8. HYPERSHIFT_PATH=${BASE_PATH}/src/hypershift
    9. HYPERSHIFT_CLI=${HYPERSHIFT_PATH}/bin/hypershift
    10. HYPERSHIFT_IMAGE=${HYPERSHIFT_IMAGE:-"quay.io/${USER}/hypershift:latest"}
    11. NODE_POOL_REPLICAS=${NODE_POOL_REPLICAS:-2}
    13. # MGMT Context
    14. MGMT_REGION=us-west-1
    15. MGMT_CLUSTER_NAME="${USER}-dev"
    16. MGMT_CLUSTER_NS=${USER}
    17. MGMT_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT_CLUSTER_NS}-${MGMT_CLUSTER_NAME}"
    18. MGMT_KUBECONFIG="${MGMT_CLUSTER_DIR}/kubeconfig"
    20. # MGMT2 Context
    21. MGMT2_CLUSTER_NAME="${USER}-dest"
    22. MGMT2_CLUSTER_NS=${USER}
    23. MGMT2_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT2_CLUSTER_NS}-${MGMT2_CLUSTER_NAME}"
    24. MGMT2_KUBECONFIG="${MGMT2_CLUSTER_DIR}/kubeconfig"
    26. # Hosted Cluster Context
    27. HC_CLUSTER_NS=clusters
    28. HC_REGION=us-west-1
    29. HC_CLUSTER_NAME="${USER}-hosted"
    30. HC_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}"
    31. HC_KUBECONFIG="${HC_CLUSTER_DIR}/kubeconfig"
    32. BACKUP_DIR=${HC_CLUSTER_DIR}/backup
    34. BUCKET_NAME="${USER}-hosted-${MGMT_REGION}"
    36. # DNS
    37. AWS_ZONE_ID="Z026552815SS3YPH9H6MG"
    38. EXTERNAL_DNS_DOMAIN="guest.jpdv.aws.kerbeross.com"

  2. Save the script to your local file system.

  3. Run the script by entering the following command:

    1. source <env_file>

    where: env_file is the name of the file where you saved the script.

    The migration script is maintained at the following repository: https://github.com/openshift/hypershift/blob/main/contrib/migration/migrate-hcp.sh.