Installation on OpenShift

This section covers what is specific to installing the CloudCasa Self-hosted server on a Red Hat OpenShift cluster: the Security Context Constraints the chart needs, the storage classes to use, and how to expose the service through an OpenShift Route.

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 OpenShift-specific differences are described here.

Supported versions

OpenShift 4.14 or later is recommended. OpenShift 4.13 and 4.12 can also be used, as long as the CronJobTimeZone feature gate is enabled. See the prerequisites in Installation for the Kubernetes and platform requirements that apply to all installations.

Security Context Constraints

On OpenShift 4.14 and later, install the server with the Security Context Constraint resources enabled:

scc:
  enabled: true

This creates the securityContextConstraint resources that the CloudCasa server components require. The chart also accepts scc.priority, which defaults to 15. Change it only when another Security Context Constraint on the cluster would otherwise be selected ahead of the CloudCasa one, in which case a higher value lets the CloudCasa constraint win.

Attention

Installing on OpenShift without scc.enabled=true is the most common OpenShift installation problem. Some deployments, such as amds-minio, may be initialized with the wrong UID or fsGroup, and the affected pods will not start correctly.

The remedy is to reinstall with the SCC enabled, which means deleting the cloudcasa-server namespace and installing again. Back up the catalog before deleting any namespace; see Catalog backup/restore. If deleting and reinstalling does not resolve it, a custom SCC on the cluster is probably taking priority, and scc.priority needs to be raised. See Known Issues for the full description.

Storage classes

Set storageClassName to a class that can successfully provision persistent volumes on the cluster, and confirm it before installing:

$ oc get storageclass

OpenShift Data Foundation classes, such as ocs-storagecluster-cephfs, are used in CloudCasa testing on OpenShift. Note that a file-based storage class is not supported for the MongoDB version used by CloudCasa, so the class backing the CloudCasa catalog must be block based. See MongoDB Setup for the MongoDB requirements.

Exposing the CloudCasa service

CloudCasa terminates TLS inside the amds-envoy-grpcapi pod itself, so an OpenShift Route in front of it must be configured for TLS passthrough rather than TLS termination, and the certificate CNAME must match the Route hostname and amdsEnvoyUrl.

A complete Route example is provided in Using OpenShift Routes. Install CloudCasa first, then create the Route, set amdsEnvoyUrl to the Route hostname, and run helm upgrade as described in Installation.

Route timeouts

Two timeout considerations apply when CloudCasa is exposed through a Route:

  • Agent connections. The CloudCasa agent maintains an always-on gRPC connection to the server, which can be idle for long periods. The OpenShift router closes idle connections by default, which shows up as agent state flapping between ACTIVE and PENDING. Raise the router timeout on the Route, using the router timeout annotation such as haproxy.router.openshift.io/timeout. See Agent timeouts for the equivalent settings on other controllers.

  • Job log downloads. Downloading large job logs through a Route can fail with a gateway timeout. The fix is the same router timeout annotation set to a longer value. The appropriate value is site-specific and depends on the size of the logs being retrieved.

Verify the installation

$ oc get storageclass
$ oc -n cloudcasa-server get pods
$ oc -n cloudcasa-server get service amds-envoy-grpcapi
$ oc -n cloudcasa-server describe cert amds-envoy
$ oc -n cloudcasa-server get route

Then confirm that all CloudCasa workloads are ready, that the web console opens at https://<amdsEnvoyUrl>, and that the certificate identity matches the endpoint.

Note

On OpenShift clusters running with SELinux in enforcing mode, the amds-fluentbit component may fail to start correctly because it cannot create its local database file. Where this occurs, the backup data path is unaffected, but the server component logs are not archived. Contact Catalogic Support rather than relaxing the SELinux configuration.

Next steps

Continue with the platform-independent tasks in Post-installation tasks, then register the clusters you want to protect.