Skip to content
Olympusx AIOlympusx AIOlympusx AI documentation

Requirements

What the cluster and your environment must provide before you install Olympusx AI. Everything on this page is something you provide or operate; the platform’s own components come with the install.

Versions

Section titled “Versions”
Minimum Notes
Kubernetes 1.27 with the Helm chart, 1.33 with the operator The operator declares a minimum of 1.33
OpenShift 4.14 with the Helm chart, 4.20 with the operator 4.20 is the first OpenShift release on Kubernetes 1.33
Helm 3.12 For the chart install, and to pull the chart
Operator Lifecycle Manager Any current release Built into OpenShift. On vanilla Kubernetes, install it with operator-sdk olm install
kubectl or oc Matching your cluster Every check in these pages uses one of them
PostgreSQL, if you bring your own 14 Tested with 16. Connect with sslmode=require or stronger
NVIDIA driver, on GPU nodes 580 The GPU inference runtime is a CUDA 13 build

Cluster

Section titled “Cluster”
  • linux/amd64 nodes for the platform. The platform’s images are built for linux/amd64 only. On an arm64 node the pull fails with no match for platform in manifest: not found, which reads like a bad credential or a corrupt image. Schedule the platform on amd64 nodes; on Oracle OKE, do not use Ampere (arm64) shapes for it.
  • An ingress controller on Kubernetes, or the default router on OpenShift. The chart renders an Ingress or two Routes; the operator chooses by asking the cluster whether it serves Routes.
  • A CNI that enforces NetworkPolicy. Four of the control plane’s internal listeners have no authentication by design: the gateway calls them on every request. The chart writes NetworkPolicies that admit only the gateway’s pods. The API server accepts those objects whether or not anything enforces them, so a clean install proves nothing. OpenShift’s OVN-Kubernetes, Calico and Cilium enforce policy. Several managed offerings do not unless policy was enabled when the cluster was created; Oracle OKE needs Calico added (Oracle OKE). Verify the installation has the check. Without enforcement, anything in the platform’s namespace can forge billing events and authorization decisions.
  • The Prometheus Operator’s CRDs, only if you turn monitoring on. They come with kube-prometheus-stack on Kubernetes and with user-workload monitoring on OpenShift. With monitoring on and the CRDs absent, the install stops rather than collecting nothing.
  • The NVIDIA GPU Operator on clusters that serve models on GPUs. Olympusx AI discovers GPU nodes from the labels it publishes. A cluster with no GPUs serves small models on CPU nodes instead.
  • The Kubernetes Metrics API (metrics-server, or your monitoring stack’s adapter) on every cluster you register, for the CPU and memory figures on the cluster pages.

The PostgreSQL operator

Section titled “The PostgreSQL operator”

The platform runs PostgreSQL clusters through the CloudNativePG operator in two places:

  • the platform’s own database, when you choose the managed database (the default on OpenShift, and the recommended production shape everywhere);
  • each tenant’s vector database, on every cluster where tenants create them.

Install it before the platform, on the install cluster and on every cluster you will register for vector databases. On OpenShift, install it from Ecosystem › Software Catalog with installation mode All namespaces on the cluster; it then runs in openshift-operators. Do not choose EDB Postgres for Kubernetes: it serves a different API group and Olympusx AI refuses it. On Kubernetes, install it from its own manifests or Helm chart, in the namespace they use by default. If it runs in any other namespace, tell Olympusx AI which (Configuration).

This command must answer, not report NotFound:

kubectl get crd clusters.postgresql.cnpg.io

The operator install refuses to start when the managed database is selected and this CRD is missing, and applies nothing.

Storage

Section titled “Storage”
What Claim Access mode
Managed database One data volume (20 GiB) and one write-ahead-log volume (10 GiB) per instance, three instances ReadWriteOnce
Bundled single-instance database (evaluation) 20 GiB ReadWriteOnce
Object store 50 GiB, from the default StorageClass ReadWriteOnce
Tracing store, if on 50 GiB ReadWriteOnce
Tenant vector databases Chosen per database in the console ReadWriteOnce

The database’s StorageClass must support ReadWriteOnce. On OpenShift Data Foundation that is the Ceph RBD class, not the CephFS class: CephFS fails when the volume attaches. Mark one StorageClass as the cluster default, or name a class for each volume.

Node disk matters too. The guardrails service’s image is about 4.5 GB to download and 11 GB unpacked, on each node that runs one of its two replicas. The document converter’s is about 2 GB. Model weights are far larger, and arrive separately (Model registry).

Network

Section titled “Network”
  • Two hostnames, one for the console and one for the gateway, with TLS certificates. Sign-in is served on the console’s hostname under /auth, so the bundled identity service needs no third name.
  • A route to your container registry. The registry address and the pull credential come with your subscription. The bundled third-party components (the database, cache, identity service, document converter, object store, tracing store and the gateway) pull from public registries; helm show values names each one. With every image mirrored into your own registry, the cluster needs no internet access (Air-gapped installation).
  • Your OIDC identity provider, if you bring one. The control plane reads its discovery document at start-up, and browsers must reach its sign-in pages.
  • An SMTP relay the cluster can reach, for invitation mail. Without one, an administrator hands new people a temporary password instead.
  • Outbound HTTPS from the platform namespace to any cloud model provider you connect (OpenAI, Anthropic, Oracle OCI Generative AI). An egress proxy can be set with the chart.
  • A load balancer idle timeout of at least 300 seconds in front of the gateway. A model call that does not stream sends nothing until the model finishes; a shorter idle timeout cuts it off first.

Capacity

Section titled “Capacity”

What the platform requests, before any model serving. Each row is the component’s total across its replicas.

Component CPU request Memory request
Control plane (×2) 500m 512Mi
Gateway (×2) 500m 512Mi
Console (×2) 100m 128Mi
Metering worker (×2) 200m 256Mi
Budget worker 50m 128Mi
Code parser 100m 192Mi
Document converter 500m 2Gi
Object store 100m 256Mi
Bundled database 250m 256Mi
Bundled cache 100m 128Mi
Bundled identity service 250m 512Mi
Total, chart defaults about 2.7 CPU about 4.8Gi

Optional components add:

Component CPU request Memory request
Guardrails service (×2) 1 CPU 4Gi
Tracing (web, worker, store and its database) 1.1 CPU 4.3Gi
Managed database (×3), in place of the bundled one 1.5 CPU 3Gi
Reranker 500m 2Gi

With guardrails, tracing and the three-instance managed database, the platform requests about 6 CPU and 16Gi. The guardrails service loads several models into each replica, and on a cold node it takes minutes to become ready. That is not a stuck install.

GPU and CPU capacity for serving models is registered after installation, per cluster.

Section titled “Related”