Skip to main content
Astra Control Service
All cloud providers
  • Amazon Web Services
  • Google Cloud
  • Microsoft Azure
  • All cloud providers

Clone and migrate apps

Contributors netapp-dbagwell netapp-mwallis
PDFs

You can clone an existing app to create a duplicate app on the same Kubernetes cluster or on another cluster. When Astra Control clones an app, it creates a clone of your application configuration and persistent storage.

Cloning can help if you need to move applications and storage from one Kubernetes cluster to another. For example, you might want to move workloads through a CI/CD pipeline and across Kubernetes namespaces.

Note If you add a namespace filter to an execution hook that runs after a restore or clone operation and the restore or clone source and destination are in different namespaces, the namespace filter is only applied to the destination namespace.
Before you begin

  • Check destination volumes: If you clone to a different storage class, ensure that the storage class uses the same persistent volume access mode (for example, ReadWriteMany). The clone operation will fail if the destination persistent volume access mode is different. For example, if your source persistent volume uses the RWX access mode, selecting a destination storage class that is not able to provide RWX, such as Azure Managed Disks, AWS EBS, Google Persistent Disk or ontap-san, will cause the clone operation to fail. For more information about persistent volume access modes, refer to the Kubernetes documentation.

  • To clone apps to a different cluster, you need to make sure that you have assigned a default bucket for the cloud instance containing the source cluster. If the source cloud instance does not have a default bucket set, the cross-cluster clone operation will fail.

  • During clone operations, apps that need an IngressClass resource or webhooks to function properly must not have those resources already defined on the destination cluster.

Clone limitations

  • Explicit storage classes: If you deploy an app with a storage class explicitly set and you need to clone the app, the target cluster must have the originally specified storage class. Cloning an application with an explicitly set storage class to a cluster that does not have the same storage class will fail.

  • ontap-nas-economy-backed applications: You can't use clone operations if your application's storage class is backed by the ontap-nas-economy driver. You can, however, enable backup and restore for ontap-nas-economy operations.

  • Clones and user constraints: Any member user with namespace constraints by namespace name/ID or by namespace labels can clone or restore an app to a new namespace on the same cluster or to any other cluster in their organization's account. However, the same user cannot access the cloned or restored app in the new namespace. After a clone or restore operation creates a new namespace, the account admin/owner can edit the member user account and update role constraints for the affected user to grant access to the new namespace.

  • Clones use default buckets:

    • During an app backup or app restore, you can specify a bucket to use. You need to specify a default bucket when you clone across clusters, but specifying a bucket is optional when cloning within the same cluster.

    • When you clone across clusters, the cloud instance containing the source cluster of the clone operation must have a default bucket set.

    • There is no option to change buckets for a clone. If you want control over which bucket is used, you can either change the bucket default or do a backup followed by a restore separately.

  • With Jenkins CI: If you clone an operator-deployed instance of Jenkins CI, you need to manually restore the persistent data. This is a limitation of the app's deployment model.

Steps

  1. Select Applications.

  2. Do one of the following:

    • Select the Options menu in the Actions column for the desired app.

    • Select the name of the desired app, and select the status drop-down list at the top right of the page.

  3. Select Clone.

  4. Specify details for the clone:

    • Enter a name.

    • Choose a destination cluster for the clone.

    • Enter destination namespaces for the clone. Each source namespace associated with the app maps to a destination namespace.

      Note Astra Control creates new destination namespaces as part of the clone operation. Destination namespaces that you specify must not be already present on the destination cluster.

    • Select Next.

    • Choose to keep the original storage class associated with the app or select a different storage class.

      Note You can migrate an app's storage class to a native cloud provider storage class or other supported storage class, migrate an app from a storage class backed by ontap-nas-economy to a storage class backed by ontap-nas on the same cluster, or copy the app to another cluster with a storage class backed by the ontap-nas-economy driver.
      Note If you select a different storage class and this storage class doesn't exist at the moment of restore, an error will be returned.

  5. Select Next.

  6. Review the information about the clone and select Clone.

Result

Astra Control clones the app based on the information that you provided. The clone operation is successful when the new app clone is in Healthy state on the Applications page.

After a clone or restore operation creates a new namespace, the account admin/owner can edit the member user account and update role constraints for the affected user to grant access to the new namespace.