Feature Update March 2024

Spring is rapidly approaching here in the US, as elsewhere in the northern hemisphere, and the days are growing longer. Outside, flowers are starting to poke their way out of ground that until recently was covered with snow. Here at Catalogic, a shiny new spring feature update of CloudCasa has emerged, bringing with it an impressive list of new features.

New Migration and Replication job types added

CloudCasa has always been useful for migration and replication of Kubenetes clusters. Its ability to back up an entire cluster (or a portion thereof), including cloud configuration, and restore it to a pre-existing or new auto-created cluster has made it valuable in many common migration and replication scenarios. However, there were previously some shortcomings when used in this fashion, including a lack of ability to schedule restores or to tie them to the success of backup jobs.

We’ve now made CloudCasa even better for cluster migration and replication by adding new migration and replication job types. You can think of these as a bit like backup and restore jobs combined, with appropriate sets of options and simplified definition workflows. You will see new Migration and Replication pages under the Clusters tab as well as corresponding new tabs on the cluster dashboard.

Migration Jobs

Migration jobs allow you to make a one-shot copy of a Kubernetes cluster, or part of a cluster. Typically, they might be used for migrating an application from one cluster to another, or a whole cluster from one cloud account to another, one cloud to another, or from on-prem to cloud or vice versa. They can also be used for migrating locally to a cluster with a new configuration.

The destination can be an existing cluster, or a new cloud cluster created on the fly using CloudCasa’s cloud integration.

Migration jobs can’t be scheduled, but can be initiated manually or via an API call. By default, they will run immediately after they are defined.

Replication Jobs

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.

The destination can be a pre-existing cluster or a new EKS, AKS, or GKE cluster cluster created on the fly using CloudCasa’s cloud integration. 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.

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

More migration and replication features will be coming to CloudCasa in the future. We’d like to hear your views on what additional features would be most useful in meeting your Kubernetes migration and replication needs.

Note: Migration and Replication job types are currently only available in the CloudCasa SaaS offering. They will be made available to self-hosted customers in the near future.

New display of job errors and warnings

A new display of job errors and warnings has been added, accessible through Activity details page for a job. Clicking on the new Errors & warnings button in the Overview tab of that page (which is itself reachable by clicking on a job in the Activity page or Activity dashboard view) will open a dialog that displays any errors and warnings associated with a completed job. Sorting and filtering is available.

The Errors & warnings button will only be active for new backup and restore jobs that have finished executing. Previously, detailed information on errors and warnings was only available by downloading the log files using the Download logs button on that page.

Advanced options for AKS node pools added to restore wizard

Several new advanced options for AKS node pool creation have been added to the Cluster Restore wizard. These include: OS Disk Type, Mac pods, Kubernetes version, Enable node public IP, Enable FIPS, Availability zones, Node labels, Tags, and Node taints. The default values of these will normally be supplied by the backup, if the backup was taken from an AKS cluster. Now the restore wizard allows you to modify these settings, or to set them initially if the backup being restored was not from an AKS cluster. If you do not supply these settings and they cannot be obtained from the backup, the AKS default settings will be used.

Storage maintenance scheduling policy

A new Storage maintenance scheduling policy setting has been added in the Advanced options section of the Configuration/Settings page. The new setting allows you to use a policy to choose a time when storage maintenance tasks such as purging and condensing will be started for all storage used by the organization. By default, maintenance tasks will be run approximately every 24 hours at a time chosen by the system. The setting applies to maintenance for all storage used by the organization, whether CloudCasa-provided or user-defined. It allows you to control the start time manually in cases where the automatically chosen time conflicts with backups or other activity. Selected policies should specify a daily interval, and should not be used for any cluster backup jobs. It should not normally be necessary to use this setting, since using the system’s default scheduing is usually sufficient.

Helm charts for agent installation updated

With this release the CloudCasa agent Helm chart has been updated to v3.4.2, supporting the latest agent builds for both amd64 and arm64 architectures. It is available from the CloudCasa Helm repo. Downstream derivatives of the agent Helm chart are used in various partner marketplaces and applications, including DigitalOcean Marketplace and Rancher Apps & Marketplace. The new version should be available in these shortly.

Kubernetes agent updates

In this update we’ve again made several changes to our Kubernetes agent to add features, improve performance, and fix bugs. However, manual updates shouldn’t normally be necessary anymore because of the automatic agent update feature. If you have automatic updates disabled for any of your agents, you should update them manually as soon as possible.

Notes

With some browsers you may need to restart, hit Control-F5, and/or clear the cache to make sure you have the latest version of the CloudCasa web app when first logging in after the update. You can also try selectively removing cookies and site data for cloudcasa.io if you encounter any odd behavior.

As always, we want to hear your feedback on new features! You can contact us using the support chat feature, or by sending email to support@cloudcasa.io.