Adding a Cluster

Before performing any backup, restore, replication, or migration operations on a cluster, you first need to register it with CloudCasa and install a CloudCasa agent on it. If you have linked one or more AWS, Azure, or GCP cloud accounts, CloudCasa will assist you by automatically discovering EKS, AKS, and GKE clusters in the linked accounts and providing options for you to automatically install the agent on them.

You can add a cluster to CloudCasa by navigating to the Clusters/Overview page and clicking Add cluster. If the cluster has been discovered from a linked cloud account, you should instead configure it by selecting Edit. You can also configure discovered clusters by navigating to Configuration/Cloud Accounts, selecting the cloud account, and choosing the Edit option from the Clusters tab.

Tip

The CloudCasa agent requires outbound connectivity to the CloudCasa service for control traffic, and also requires outbound connectivity to the selected object storage to perform backup & restore operations. See Network Connectivity for details.

The cluster registration process is slightly different depending on whether you wish to configure the cluster normally (i.e. for “Pro” backups, the default) or whether you with to manage a Velero instance on the cluster.

Adding a CloudCasa Pro cluster

Take the following steps to add a cluster in your CloudCasa account:

  1. Leave the Manage an existing Velero instance option set to off (the default).

  2. Fill in the following fields:

    Name

    Enter a name for the cluster.

    Description (optional)

    Enter a description for the cluster.

    Add tags (optional)

    Enter the key-value pairs for the tags of the cluster. For example, team:marketing.

    Advanced options ► Default Storage for cluster (optional)

    Select the default backup storage location for this cluster by choosing one of the following:

    • Use global default - Use the default storage set for your organization (default)

    • CloudCasa Storage - Use CloudCasa storage in the selected cloud and region

    • My Storage - Use user-provided object storage.

    Note that this default location can be overridden on a per-backup basis.

    See also

    See the following topics for more information about setting storage defaults:

    Advanced options ► Maximum Concurrent Jobs

    Controls the number of concurrent jobs that are allowed to run on the cluster. The limit is set to 1 by default, but can be changed to any value between 1 and 32. Jobs that exceed this limit or that cannot run concurrently with already executing jobs will be queued.

    Limitations on concurrent job execution:

    • Full cluster backups, delete backup jobs, and restore jobs with the option “Include all cluster-scoped resources” selected run exclusively. No other jobs are allowed to run while any one of these is running.

    • Two jobs that back up or restore the same namespace cannot run at the same time.

    • The snapshot phase of backups jobs is serialized, but this phase is relatively short.

    Note that for higher values, you may need to adjust CPU/memory limits for the containers “kubeagent” and “backup helper”. See below for details. Higher CSI snapshot timeouts may also be required when running concurrent jobs.

    Advanced options ► Kubelet pods directory

    This option was added to support the new Read data from underlying host volume backup method. It allows you to set the base path where CloudCasa will look for pod PV data when that method has been selected for a PV backup operation on the cluster. The path from which pod PVC data will be read is based on this path, and is fully specified as: <kubelet-pods-directory>/<pod-id>/volumes/*/<pvc-id>/mount. If this parameter is not configured it defaults to “/var/lib/kubelet/pods”, which should be correct for most clusters.

    Advanced options ► Disable automatic agent updates

    Enabling this option will prevent the agent from automatically updating itself when an update is available. This is generally not recommended.

    Advanced options ► Image pull secret

    The name of the image pull secret in the cloudcasa-io namespace that will be used to pull CloudCasa agent images from the registry. Defining this may be necessary if you wish to pull agent images from your own registry (see below), or if you wish to authenticate to a public registry to prevent throttling of pull requests. By default, no secret will be used.

    Note: This option is only valid for agents installed using the kubectl method. Setting it will have no effect on agents installed installed using the EKS add-on or via other methods.

    Note: When setting or changing the image pull secret for a cluster that already has the agent installed, the agent must first be removed, the secret created in the cloudcasa-io namespace and configured here, and then the agent re-installed.

    See also

    For more information about defining secrets for private registry access, see the Kubernetes Documentation.

    Advanced options ► Private container registry for agent

    The private container registry from which CloudCasa agent container images will be pulled. For example, 12345678910.dkr.ecr.us-east-1.amazonaws.com. Defining this is necessary only if this cluster cannot pull images from the default public container registry (e.g. Docker Hub). Note that agent automatic updates are disabled if a private container registry is defined.

    Clicking on the “show images” option under this field will display a list of the images that will need to be present in the private repo. You should transfer these from the appropriate public repo (e.g. Docker Hub) before proceeding, and arrange to update them in the future as necessary.

    Note: This option is only valid for agents installed using the kubectl method. Setting it will have no effect on agents installed installed using the EKS add-on or via other methods.

    Advanced options ► Resource config

    This section allows you to set container CPU Request, CPU Limit, Memory Request, and Memory Limit parameters for the Kube Agent, Kube Agent Manager, and Backup Helper components of the CloudCasa agent.

    Click Register.

  3. A dialog will open showing you different installation options for CloudCasa’s lightweight agent. Depending on the type of cluster you are registering, you may see options for automatic installation and manual installation using different methods (kubectl, Helm, etc.). To install using kubectl, you can simply copy the displayed command and run it on a host where kubeconfig is set up to connect to the cluster being registered. Click Close when you are done.

    See also

    See Agent Installation for more details on available agent installation methods.

  4. The Edit Cluster pane is then displayed, showing the cluster ID and status, and allowing you to make changes to cluster settings.

    Click on the Permissions icon to manage cluster permission settings. This allows you to create an ACL to grant specific permissions to the cluster to users or groups, for all or selected namespaces. Note that permissions assigned at the cluster level add to permissions the user or group may have from user groups and roles.

    Click the Install icon to re-open the Install Agent dialog to help you install or re-install the agent.

    Click Save to close the pane. Ensure that you can see the new cluster in the list and that its status has changed to ACTIVE before attempting backup and restore operations.

Adding a Velero cluster

Take the following steps to add a cluster in your CloudCasa account:

  1. Click Add cluster + to open the Add cluster pane.

  2. Enable the manage an existing Velero instance option. Velero must already be installed on the cluster. The configuration of your existing Velero installation will be discovered, but not modified.

  3. Fill in the following fields:

    Name

    Enter a name for the cluster.

    Description (optional)

    Enter a description for the cluster.

    Add tags (optional)

    Enter the key-value pairs for the tags of the cluster. For example, team:marketing.

    Advanced options ► Velero namespace to manage (optional)

    Enter name of the Velero namespace to manage. CloudCasa will normally automatically detect a Velero instance in a cluster. If multiple installations exist on a cluster, use this field to guide Velero to manage a specific instance. CloudCasa for Velero can only manage one Velero instance per cluster.

    Advanced options ► Disable automatic agent updates

    Enabling this option will prevent the agent from automatically updating itself when an update is available. This is generally not recommended.

    Advanced options ► Image pull secret

    The name of the image pull secret in the cloudcasa-io namespace that will be used to pull CloudCasa agent images from the registry. Defining this may be necessary if you wish to pull agent images from your own registry (see below), or if you wish to authenticate to the public registry to prevent throttling of pull requests. By default, no secret will be used.

    Note: When setting or changing the image pull secret for a cluster that already has the agent installed, the agent must first be removed, the secret created in the cloudcasa-io namespace and configured here, and then the agent re-installed.

    See also

    For more information about defining secrets for private registry access, see the Kubernetes Documentation.

    Advanced options ► Private container registry for agent

    The private container registry from which CloudCasa agent container images will be pulled. For example, 12345678910.dkr.ecr.us-east-1.amazonaws.com. Defining this is necessary only if this cluster cannot pull images from the default public container registry (e.g. Docker Hub). Note that agent automatic updates are disabled if a private container registry is defined.

    Clicking on the “show images” option under this field will display a list of the images that will need to be present in the private repo. You should transfer these from the appropriate public repo (e.g. Docker Hub) before proceeding, and arrange to update them in the future as necessary.

    Note this setting is applicable only to CloudCasa Agent images and NOT to your Velero images.

    Click Register.

  4. A dialog will open showing you different installation options for CloudCasa’s lightweight agent. Depending on the type of cluster you are registering, you may see options for automatic installation and manual installation using different methods (kubectl, Helm, etc.). To install using kubectl, you can simply copy the displayed command and run it on a host where kubeconfig is set up to connect to the cluster being registered. Click Close when you are done.

    See also

    See Agent Installation for more details on available agent installation methods.

  5. The Edit Cluster pane is then displayed, showing the cluster ID and status, and allowing you to make changes to cluster settings, including to cluster access permissions by clicking the Permissions icon. Click Save to close the pane. Ensure that you can see the new cluster in the list and that its status has changed to ACTIVE before attempting backup and restore operations.

Removing a cluster

In the cluster list, click Remove and follow the instructions. If jobs are defined for the cluster, you may be prompted to remove those first.

Attention

After removing the cluster, manually remove any PV snapshots that were created by CloudCasa as part of the cluster’s Snapshot backups.

After the cluster is removed from CloudCasa, you should take the appropriate steps to uninstall the CloudCasa agent, depending on how it was installed.

See also

See the appropriate page in the Agent Installation section for uninstall instructions.

If CloudCasa was managing Velero on the cluster, you will no longer be able to view or manage the Velero resources on the cluster through CloudCasa, but the Velero configuration on the cluster will not be affected.