Supported Kubernetes Clients
Overview
CloudCasa supports all CNCF certified Kubernetes distributions and hosted services based on Kubernetes version 1.20 or higher as clients.
Through Catalogic Software’s many industry partnerships, compatibility has been verified with all major Kubernetes distributions (e.g. Red Hat OpenShift, SUSE Rancher, VMware Tanzu) and cloud services (e.g. AKS, EKS, GKE, DigitalOcean, IBM Cloud, OKE, OVHcloud).
AMD64 (for agent & self-hosted server) and ARM64 (for agent) CPU architectures are supported with Linux worker nodes. Contact CloudCasa support for inquiries regarding other configurations.
For backups utilizing snapshots, CSI drivers that support the CSI snapshot interface must be used, and the cluster must be configured to support snapshots. Live backups can be used for any PVs that do not support snapshots.
See also
Support notes for specific Kubernetes distributions/services
AKS
Enhanced support for Microsoft Azure Kubernetes Service (AKS) includes Azure cloud integration features such as cloud configuration backup and full-stack recovery.
See also
EKS
Enhanced support for Amazon Elastic Kubernetes Service (EKS) includes AWS cloud integration features such as cloud configuration backup and full-stack recovery. An EKS add-on is also available for installing the CloudCasa agent.
See also
GKE
Enhanced support for Google Kubernetes Engine (GKE) includes GCP cloud integration features such as cloud configuration backup and full-stack recovery.
See also
MicroShift
Red Hat MicroShift is a Kubernetes distribution that is optimized for edge computing. The default storage provisioner on MicroShift is LVMS, which is based on TopoLVM. CloudCasa can back up PVCs using this provisioner using all available backup methods, with the following caveats.
Snapshot-based backups (those using backup method Read data from snapshot) require CSI snapshots to be created, but note that LVMS/TopoLVM supports CSI snapshots only for thin-provisioned volumes.
On MicroShift, CloudCasa’s live backup methods for PVs (even those not using TopoLVM) require that a security context constraint (SCC) be added to the service account used by the data mover pod. The exact SCC varies depending on the particular live backup method used.
For the method Read data from underlying host volume, a “privileged” SCC needs to be added as follows:
oc adm policy add-scc-to-user privileged -z cloudcasa-io -n <PVC-NAMESPACE>
The same will work for the method Read data from PVC as well, though you can also use “anyuid” which is less powerful than “privileged”.
oc adm policy add-scc-to-user anyuid -z cloudcasa-io -n <PVC-NAMESPACE>
For restores, first create the namespace if it doesn’t already exist:
kubectl create ns <RESTORE-NAMESPACE>
and then:
oc adm policy add-scc-to-user anyuid -z cloudcasa-io -n <RESTORE-NAMESPACE>
One important thing to note is that the service account “cloudcasa-io” is created by the CloudCasa agent on the fly before starting the data mover pod (in the namespace where PVCs are present), and is deleted once backup or restore is completed. However, you can still add SCCs as described above and the “cloudcasa-io” service account will be set up with the required permissions when it is created by the agent.
OpenShift
CloudCasa Agent installation is also available via a Red Hat certified operator.