Installation on SUSE Rancher (RKE2)

This section covers installing the CloudCasa Self-hosted server on SUSE Linux Enterprise Server (SLES) with RKE2, including the host preparation and the RKE2 specifics that the generic procedure does not cover.

Note

The generic installation procedure, the full list of Helm values, and the complete prerequisites are documented in Installation, which you should read first. Only the SLES and RKE2 specifics are described here.

Attention

The topology described here is an evaluation and proof-of-concept deployment: a single-node RKE2 cluster on one SLES virtual machine. It is sufficient for evaluating CloudCasa Self-hosted through initial web console access, but it is not a production architecture. A production deployment needs a supported multi-node cluster, a durable storage class, and the sizing analysis described in Resource Limits.

To install the CloudCasa agent on a Rancher-managed downstream cluster you want to protect, which is a separate task from installing the server, see Rancher agent.

Evaluation topology

Component

Role

SUSE Linux Enterprise Server

Operating system for the CloudCasa management host. SLES 15 SP7 is used here.

RKE2

The Kubernetes distribution hosting the CloudCasa server, deployed as a single node.

CloudCasa Self-hosted

The backup control plane, installed with the cloudcasa-server Helm chart.

Protected clusters

Separate clusters running the CloudCasa agent, for example SUSE Virtualization or Harvester clusters.

The CloudCasa server and the clusters it protects are separate clusters. The management host must be able to reach the protected clusters’ management networks, and the agent on each protected cluster must be able to reach the CloudCasa endpoint, its image registry, and the backup storage.

Host envelope

The following are evaluation values for the management virtual machine:

  • 4 vCPU minimum

  • 8 GB memory minimum, 16 GB recommended

  • 100 GB operating system disk

  • A static IP address is recommended

Attention

These are lab values. 8 GB cannot accommodate the sum of the documented CloudCasa component memory limits, their replicas, RKE2, ingress, and storage together with transient workloads. Even 16 GB needs workload-specific headroom analysis before it is used outside an evaluation. See Resource Limits for the documented component requests and limits.

Prepare SLES

Enable the SLES Containers module and PackageHub, then install the base packages:

$ SUSEConnect -p sle-module-containers/15.7/x86_64
$ SUSEConnect -p PackageHub/15.7/x86_64
$ zypper refresh
$ zypper update -y
$ zypper install -y curl wget tar open-iscsi nfs-client jq
$ systemctl enable --now iscsid

open-iscsi and nfs-client are required by the storage provisioners commonly used with RKE2.

Attention

Do not disable firewalld to make the installation work. Define explicit firewall rules instead, preserving access to the CloudCasa endpoint, the image registry, the authentication provider, the backup storage, and the management networks of the clusters you intend to protect. The full list is in Networking requirements.

Install and verify RKE2

Install a pinned, organization-approved RKE2 release that provides a Kubernetes version supported by CloudCasa, as listed in the prerequisites in Installation. Pin the version rather than taking whatever the convenience installer offers, so that the cluster you evaluate is the cluster you can reproduce.

Configure kubectl to use the RKE2 kubeconfig, add the RKE2 binary directory to the administrative path, and verify the node before installing CloudCasa:

$ export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
$ kubectl get nodes -o wide
$ kubectl version
$ kubectl get storageclass

Storage class

CloudCasa requires a storage class that can provision persistent volumes for the server components and for the catalog database.

Attention

A node-local provisioner such as the Rancher Local Path Provisioner is acceptable only for an evaluation. It provides neither durability nor high availability, so the CloudCasa catalog would not survive the loss of the management node. Use a tested, supported storage class for production, and for any deployment whose catalog must survive node loss.

The storage class backing the catalog must also be block based. A file-based storage class is not supported for the MongoDB version used by CloudCasa. See MongoDB Setup.

Install the CloudCasa server

Follow the full procedure in Installation. The sequence is:

  1. Install Helm 3 and the cert-manager version required by Certificate Configuration.

  2. Create the cloudcasa-server namespace and either a certificate Issuer or the required TLS secrets.

  3. Create the myregistrykey image pull secret using the registry credentials from the CloudCasa support portal.

  4. Add the credential-protected CloudCasa Helm repository.

  5. Create a values file containing the storage class, the license, the authentication allow-lists and site administrators, the service exposure, and the external Envoy address.

  6. Install the chart with your values file.

  7. Expose amds-envoy-grpcapi, set amdsEnvoyUrl, refresh the certificate if required, and run helm upgrade.

For example:

$ helm install cloudcasa-server cloudcasa/cloudcasa-server \
    --namespace cloudcasa-server --create-namespace \
    --values my_values_file.yaml --wait --timeout 15m

Note

Use local authentication only for an evaluation. Create a unique, high-entropy password, list the identity in both the login allow-list and the site administrator setting, restrict access to the values file, and replace local authentication with an external provider before production use. See Authentication.

Endpoint, ingress, DNS, and TLS

Getting these four to agree is the step most likely to go wrong on RKE2, because the ingress host, the certificate identity, the DNS record, and amdsEnvoyUrl are configured in different places and must all name the same endpoint.

Before exposing CloudCasa:

  1. Check which ingress controller is actually installed on the RKE2 cluster. Do not assume it is NGINX.

  2. Choose one stable external FQDN, or one IP address.

  3. Make the ingress host, amdsEnvoyUrl, the DNS record, and the certificate identity all agree.

  4. Apply the configuration for your controller from Networking, which has worked examples for NGINX ingress, Traefik, and Istio.

  5. Preserve the long-lived agent connection. The CloudCasa agent holds an always-on gRPC connection that can be idle for long periods, and controllers close idle connections by default. For NGINX, set nginx.ingress.kubernetes.io/proxy-read-timeout: "600"; for Traefik, disable the default responding read timeout. See Agent timeouts.

  6. Confirm the endpoint is reachable both from the administrators’ browsers and from every cluster you intend to protect.

Disconnected is not air-gapped

Installing from the public registries and then operating the cluster without ongoing internet access is a pull-once, disconnected-after-install deployment. It is not an air-gapped deployment, and should not be described as one.

A genuine air-gapped installation additionally requires that you:

  • download the versioned chart archive and the image list from the CloudCasa support portal

  • mirror every server and agent image into an internal registry, preserving the required image paths

  • configure images.userContainerRegistry, images.registry, and images.agentRegistry

  • ensure the server and every protected cluster can pull only from the internal registry

See the air-gapped installation section and Custom Container Registry Setup in Installation.

Verify the installation

$ kubectl get nodes
$ kubectl get storageclass
$ kubectl -n cloudcasa-server get pods
$ kubectl -n cloudcasa-server get service amds-envoy-grpcapi
$ kubectl -n cloudcasa-server describe cert amds-envoy

Then confirm that:

  • all required CloudCasa workloads are ready

  • the web console opens at https://<amdsEnvoyUrl>

  • the certificate identity matches the endpoint

  • the management cluster can reach the required external services, or the approved internal mirrors

  • each cluster you intend to protect can reach the CloudCasa endpoint, the image registry, and the planned backup storage

This validates the server installation only. Registering clusters and running a backup and restore are separate steps; continue with Post-installation tasks.