Feature Update June 2024

It’s been over two months since our last significant CloudCasa feature release, so we decided it was time to release a few more great CloudCasa features! The updates in this release run the gamut from new restore options to performance improvements to UI changes, but there was a focus on features related to AWS EKS, Azure AKS and Arc, and enhancements to our recently released migration and replication features. Some features listed in these notes were introduced in interim minor updates.

General Updates

Email alert notifications

Email notification for alerts is now enabled by default for new users. This setting can be modified in the User Settings page, accessible from the User menu (in the upper right corner of the UI). We suggest that all users consider enabling email alert notifications, since they can prevent unpleasant surprises if you don’t log in and check your alerts regularly. We’ve also made some improvements to the notification emails themselves, including the addition of a link to the page where they can be controlled. Subscription-related alerts now generate email notifications regardless of the user notification setting.

Support for Azure Government cloud storage

Support for using Azure Blob Storage in the Azure Government cloud has been added to CloudCasa. There is now an Azure Cloud option on the Azure Provider page in the Add Storage wizard, with possible values “Public” and “Government”. It defaults to “Public”, which was the only option previously available.

Cluster-scoped resource controls

A new option has been added to restore, migration, and replication job definitions to allow more control over when cluster-scoped resources are restored. If anything other than “Full cluster” is selected for restore or migration (i.e. namespaces are selected or excluded), you will be given the option to include all cluster-scoped resources. If selected, the system will attempt to restore all cluster-scoped resources. Otherwise, only cluster-scoped resources associated with selected resources (e.g. PVs associated with PVCs) will be restored. “Full cluster” restores aways restore cluster-scoped resources. Previously, partial restores only included associated cluster-scoped resources.

Pause function for replication job scheduling

Scheduling of replication jobs can now be paused and resumed. Pause/resume controls have been added to the jobs list on the Clusters/Replication page, and also to the replication job dashboard. These mirror the pause/resume controls which have been available for scheduled backup jobs.

UI change for cluster addition

The way Velero management, as opposed to “Pro” backup functionality, is selected at cluster addition time has been changed. The UI has been changed from using radio buttons that always forced users to choose a selection to using a Manage an existing Velero instance toggle that is off by default. The functionality has not changed.

CloudCasa for Azure Updates

Azure Arc support

CloudCasa for Azure, our service offering which allows payment through the Azure Marketplace, is now available for Azure Arc clusters as well as for AKS clusters. A new Azure marketplace listing called “CloudCasa for Azure Arc” has been created to facilitate agent installation on Azure Arc clusters.

The two CloudCasa Azure Marketplace listings now available are:

• CloudCasa for Azure Arc

• CloudCasa for AKS

Billing and Service Plan page updates

Several changes were made to the Service Plans and Billing & Payments pages for CloudCasa for Azure users. In particular, a new Marketplace tab has been added to the Service Plans page.

Installation instructions update

The on-screen agent installation instructions show when adding a cluster have been updated for CloudCasa for Azure subscriptions. Links to the Azure marketplace listings and to appropriate Azure portal installation pages for the agent are now provided.

Metering and billing

Usage metering/charging for CloudCasa for Azure clusters is now done solely by Azure Marketplace mechanisms, based on the metric “hour/pereverynodeincluster”. This is currently necessary to support Azure Arc clusters, but it means that we are not able to charge for CloudCasa storage usage. Because of this, we have limited organizations using CloudCasa for Azure subscriptions to using only the included 100 GB of CloudCasa storage. For now, we recommend that CloudCasa for Azure users configure their own object storage under Configuration/Storage. Contact CloudCasa support if you have a need to use more CloudCasa storage with your CloudCasa for Azure subscription.

AWS EKS Feature Updates

Option added to enable encryption of secrets

An Enable secrets encryption switch and KMS Key ARN field has been added to the EKS Options step in the restore, migration, and replication wizards. This allows you to enable encryption of Kubernetes secrets, and select the KMS key to be used, when creating EKS clusters during restore, migration, or replication. If the source cluster was EKS and had encryption of secrets enabled, the Enable secrets encryption option will be enabled by default. By default, the KMS Key field will be populated with the key from the source cluster for EKS-to-EKS restores, replications, or migrations within the same account and region. You must supply a KMS Key for cross-region or cross-account restores, or choose to disable secrets encryption. The selected key will be validated by CloudCasa.

Configuring volume encryption for volumes defined in launch templates

With EKS clusters, EC2 launch templates can be used to define local EBS volumes for node groups, and optionally to enable encryption and define encryption keys for them. CloudCasa now supports restoring, selecting, and modifying launch templates when creating new EKS clusters during restore/migration/replication. You are now able to select an existing launch template or choose to re-create one from the backup when customizing node pool configurations. If you choose to re-create one from the backup, you will have the option of enabling/disabling encryption and selecting a key for each EBS volume listed in the launch template. To support this, EC2 launch templates are now included in EKS cluster backups when the appropriate AWS account has been linked.

AWS User field now optional

The AWS user field no longer requires an IAM user to be entered when defining a restore or migration/replication jobs that creates an EKS cluster. This change allows more flexibility in how access is granted to automatically created clusters, especially when using OIDC identity providers. If an IAM user is entered, it will be granted admin access to the cluster once the restore/replication is complete, as before. If no IAM user is provided, you will need to manually grant appropriate access to the cluster using the AWS console or API after it has been created. Note that CloudCasa will set the authentication mode of the created cluster to “EKS API and ConfigMap” so that this is possible. A message will appear in the log indicating that you should manually add an IAM access entry and/or associate an OIDC identity provider.

Default setting for tmp disk size

The tmp disk size for EKS nodes is now set to 20GB by default if it is not set by the user (i.e. the field is left blank in the UI) on EKS cluster creation during restore, migration, or replication. Note that this only applies to node pools created without using EC2 launch templates.

Permissions checked on EBS volume encryption keys

CloudCasa now checks for the correct permissions on KMS keys used for EBS volume encryption when creating EKS clusters during restore/migration/replication operations. You will now receive an error when attempting to create the job definition if the permissions on supplied KMS keys are incorrect. Additional permissions have been added to the CloudFormation stack to permit this.

Manual installation of agents for created clusters

Changes have been made to allow manual installation of the CloudCasa agent on private EKS clusters (i.e. those with non-public control plane endpoints) created during restore/migration/replication operations. The system will now wait up to 60 minutes for the agent to be installed and for the cluster state to become active before proceeding. A message will be logged indicating that manual installation is necessary. This functionality should only be needed in special circumstances, since the agent it normally installed automatically.

Advanced option added to control clean-up on failure

An option Do not clean up created cluster and dependent resources on error has been added to disable EKS cluster cleanup on restore job failure. It is located in the Destination page of the restore wizard under Advanced Options. If enabled, a message will appear in the log indicating which resources should be removed manually. This option is mainly useful for debugging and should not normally be needed.

Snapshot controller add-on used

CloudCasa will now install the snapshot controller on EKS using Microsoft’s EKS add-on when creating a cluster during restore. Previously, it was installed from the source repo.

Permissions removed after cluster creation

EKS cluster access for the CloudCasa cross-account role is now automatically removed after an EKS restore completes.

AWS CloudFormation stack update

Our CloudFormation stack template has been updated in this release in order to support the EKS restore and migration enhancements. You’ll need to apply the new version to any previously configured AWS cloud accounts in order to take advantage of these features. You can see which accounts need to be updated by going to the Configuration/Cloud Accounts page. Accounts needing updates will be flagged with an attention icon. Just click on the icon to begin the process.

As part of this update, new permissions were added to support the new features. See Permissions required for AWS account linking for the updated list of all permissions used.

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.