CloudCasa Kubernetes Replication Guide

CloudCasa replication jobs allow you to replicate a cluster, or part of a cluster, on a continuing periodic basis. Typically, they might be used for maintaining a DR or hot standby cluster, or for periodically creating a dev/test replica of a production cluster.

Replication jobs can be scheduled using policies, as backups can. They can also be initiated manually or via an API call.

Step 1 - Create an Account

First, create a CloudCasa account if you haven’t done so already. Just go to https://home.cloudcasa.io and select “Sign Up”. No payment information is required for the Free service plan. Once you’ve signed in, you can invite other people to join your organization under Configuration/Users.

Step 2 - Configure your AWS, Azure, and GCP accounts (optional)

CloudCasa optionally allows the replication target cluster to be an auto-created EKS, AKS, or GKE cluster. Adding your cloud account(s) under Configuration/Cloud Accounts will grant CloudCasa the access it needs to create the target clusters. It also allows CloudCasa to auto-discover your EKS, AKS, and GKE clusters, and save EKS, AKS, and GKE cluster parameters. For some configurations, it also gives you the option of auto-installing the agent.

See also

For more information on adding cloud accounts, see Cloud Accounts.

Step 3 - Add your cluster(s)

You’ll need to register with CloudCasa each cluster that you wish to replicate, if they haven’t been added already. Note that for replication you’ll need to add the clusters as CloudCasa Pro clusters, i.e. leave the “Manage an existing Velero instance” option disabled. If your clusters were auto-discovered, you’ll just need to find them in the Clusters list under your cloud account in Configuration/Cloud Accounts and click on the install icon for each one. If not, you can add them manually by clicking “Add cluster” under Clusters/Overview. Then enter your cluster name and description and click “Register cluster”. Either way, you will see a cluster ID and a kubectl command to run that will install a lightweight agent on the cluster. If you are installing the agent via our Helm chart or via a partner marketplace instead, make a note of the Cluster ID and follow the instructions specific to your preferred installation method. Once installed, the agent will connect to and register itself with the CloudCasa service, completing the process.

If you don’t wish to have CloudCasa auto-create a destination cluster for you, you will also need to add your destination cluster to CloudCasa.

See also

For more information on adding clusters to CloudCasa, see Adding a Cluster.

Step 4 - Define a replication job

Go to the Clusters/Replication page and click “Define Replication”. The cluster replication wizard will open. It has several steps. First, select the cluster you wish to replicate.

Next, choose what you wish to replicate. Various options are available to select resources by namespace, resource type, or label. The default is to replicate the full cluster, and either this or selected namespaces is what you should normally choose. The Advanced options section allows you to choose the location for temporary storage for the replication job, to select copy methods, and to set several less commonly needed performance-related options. These can usually be left at their default values.

Next select the destination cluster for replication. You can choose a pre-existing cluster, or you can choose to create a new EKS, AKS, or GKE cluster. If you choose an existing cluster, you must select specific namespaces for replication. These namespaces will be deleted and re-created on the destination cluster with each run on the replication job. If you choose to create a new cluster, the entire new cluster will be deleted and re-created with each run of the replication job.

See also

For more information on creating clusters with CloudCasa, see: Creating Clusters With CloudCasa.

Next choose any required restore transforms. For replication jobs, changing storage classes and preserving automatically assigned node ports are typically the most important.

Next you can select application hooks to execute before and after replication. These are generally only needed for special applications, like databases, that need to be put in a specific state for replication.

See also

For more information on application hooks see App Hooks.

Next you can select a policy to apply to the replication job. The policy will determine the schedule that the job will be run on. If you create a replication job with no policy defined, it will not run automatically but can be initiated manually through the UI or API.

Finally, you will be presented with a summary of your selections and prompted to enter a name for the replication job. You can also enter optional tags to help identify it. Leave the “Run now” option enabled to start the replication job right away, or toggle it off so you can run it later.

See also

For more information on migration job creation, see Cluster Replication Wizard.

While the replication job is running, you can watch its progress on the dashboard status page.