Clusters

Platform › Infrastructure › Clusters lists the clusters Olympusx AI serves models on, the GPU nodes it discovered on them, and the pool of nodes it is allowed to use. Each cluster has its own page with its nodes, GPU telemetry, GPU partitioning, workloads, namespaces, internet access, image registry and tenants.

Who can open it

Platform administrators only. Tenant roles do not see the page, and the API refuses its routes to them.

Three numbers that are easy to confuse

Term	What it is	Who changes it
Discovered	Every node Olympusx AI found on a registered cluster, with its hardware. Discovery refreshes it every 5 minutes and on Rediscover.	Nobody: it is read from the cluster.
Managed (the serving pool)	The GPU nodes you have chosen to let Olympusx AI use. Discovery never adds a node to it or takes one out.	You, per node.
Capacity envelope	What one tenant may use on one cluster: CPU cores, memory, storage and GPUs by flavor. Granting it is what gives the tenant access to the cluster.	You, on Tenants.

The envelopes on a cluster must fit its pool, and the project quotas in a tenant must fit its envelope. Olympusx AI holds this in both directions: you cannot grant more than the pool holds, and you cannot shrink the pool or an envelope below what has already been granted out of it.

What you see

On a new installation

With no cluster registered, the page shows No clusters registered and a Register cluster button. An installation made with the operator registers the cluster it runs on by itself, so it starts with one row.

The Discovered tab

The Registered clusters table, with Search clusters and Register cluster in its toolbar.

Column	What it shows
Cluster	The name, linking to the cluster’s page. A home tag marks the cluster Olympusx AI is installed on.
Platform	OpenShift, Oracle OKE, Amazon EKS, Google GKE, Azure AKS, or Kubernetes, as discovery recognised it.
Status	Connected, Disconnected (the API server could not be reached; usually transient) or Error (it answered and refused: a bad token, missing permissions or an untrusted certificate). Unknown before the first discovery.
Version	The OpenShift version when there is one, otherwise the Kubernetes version.
Nodes, GPU nodes	Counts from the last discovery.
GPU cards	Physical cards.
Schedulable devices	What the nodes advertise to the scheduler. With MIG on, one card can advertise several devices.

The Managed tab

Three tiles, Platform, Managed nodes and Allocatable GPUs (with “In the pool: n” under it), then the Serving pool by GPU type table: GPU type, Allocatable GPUs, Total GPUs, Schedulable nodes, Nodes and GPU memory.

When GPUs were found but none are managed, the tab shows Nothing is serving yet, with a button to open the cluster when there is only one.

Register a cluster

Registering takes the cluster’s API address and a token for a service account on that cluster. The token is sealed at rest with the platform’s master key and is never shown again, by the console or the API.

Grant the full permission set before you register

Registration only needs to read nodes, so a read-only token registers and discovers without complaint. Serving models, creating project namespaces and provisioning vector databases need more, and a token without it fails later, at the first project quota or deployment. For a cluster that will serve, give the token the permissions in What the cluster credential needs from the start.

1. Select Register cluster. The Register a cluster dialog opens on its first step.

2. Permissions. The step shows a command block that creates a namespace olympus-system, a service account olympus-discovery, a read-only cluster role bound to it and a long-lived token for it, then prints the API URL, the token and the CA certificate. Select Copy the commands and run them where you have cluster-admin rights, such as a bastion host. The commands use oc; on other distributions use the kubectl equivalents. Select Next.

3. Connection. Fill in:

   Field	Rule
   Name	3 to 40 characters: lowercase letters, digits and hyphens, starting and ending with a letter or digit. Unique on the platform.
   API URL	The cluster’s API server, for example https://api.cluster.example:6443. Required.
   Bearer token	The service account token.
   CA certificate (PEM, optional)	The certificate that signed the API server’s. Empty uses the system’s trusted roots.
   Skip TLS verification (dev only)	Off. Leave it off on any cluster that matters.
   This cluster cannot reach the internet	On for an air-gapped cluster. Model weights are then never fetched on it: imports for it run through its bastion, or on another cluster.

   Select Test connection. Connected reports the nodes, GPU nodes, GPUs and OpenShift version found. The cluster did not accept the connection quotes what the cluster said. Select Next; a missing field is named there.

4. Discovery. Olympusx AI lists the cluster’s nodes: Node, Role, GPU type, GPUs, allocatable/total, vCPUs, Memory and Status. Discovery did not complete offers Retry discovery. A cluster that returns no nodes usually means the token cannot list them.

5. Summary. Check the name, the API URL, the token (“Provided, sealed at rest”), the CA (“System roots” or “Provided”), TLS, Internet access and the counts, then select Register cluster.

The cluster’s page opens. Nothing on the cluster is changed by registering it.

Leaving the dialog halfway asks first: what you entered is lost.

What the cluster credential needs

Apply these to a service account on the cluster being registered, not on the one Olympusx AI runs on, unless they are the same cluster. An installation made with the operator grants its own cluster these permissions itself.

Purpose	Kubernetes resources and verbs	If you leave it out
Discovery	get, list on nodes, namespaces, persistentvolumeclaims, resourcequotas; on OpenShift also clusterversions, infrastructures, ingresses in config.openshift.io	Registration succeeds and the cluster stays Unknown. The OpenShift resources only add version and platform detail.
Project namespaces	get, list, create, patch, update on namespaces (no delete); full write on resourcequotas, limitranges, networkpolicies, roles, rolebindings (with escalate and bind), and get, list, create, patch, update on serviceaccounts	Setting a project’s quota on the cluster fails.
Model serving	Full write on deployments, horizontalpodautoscalers, services, configmaps; get, list on pods and endpointslices; get on pods/log; get, list on customresourcedefinitions	Deployments fail before anything is created. A deployment with a replica range needs horizontalpodautoscalers.
Short-lived jobs	get, list, create, patch, delete on jobs	Model imports, runtime inspections and the internet-access check cannot run. patch is required as well as create.
Secrets	get, list, create, patch, update, delete on secrets	Pull secrets, database credentials and backup keys cannot be placed. This is the broadest grant: bind it per namespace if your policy requires, at the cost of Olympusx AI creating namespaces it was not pre-granted.
Vector databases	Full write on the database operator’s clusters and scheduled backups	Tenants cannot provision vector databases on this cluster. Omit it if they never will.
Live telemetry	get on pods/proxy; get, list on pods in metrics.k8s.io	GPU telemetry and namespace CPU and memory stay empty, with no permission error shown.
Events	create, patch on events; get, list on events	Optional. Workloads stop explaining themselves in describe, and a vector database page’s events cannot be read.
GPU partitioning, read	get, list on clusterpolicies in nvidia.com	Optional. Without it Olympusx AI reads the default MIG configuration name.
GPU partitioning, write	patch on nodes	Optional, and leaving it out is a real choice: Olympusx AI can show and plan partitioning but never apply it, which suits a production cluster. Nothing here evicts pods.
Operator-managed serving	Full write on modeldeployments in olympus.olympusx.ai	Only when the Olympusx AI operator on that cluster renders deployments.

Prefer a bound token with an expiry over a long-lived one. Olympusx AI reads the stored token on every discovery, so rotating it means pasting a new one with Edit connection; nothing restarts.

Put GPU nodes in the serving pool

1. Open the cluster and stay on the Nodes tab.
2. Select GPU (n) to list GPU nodes only.
3. Switch Managed to On for each node Olympusx AI may use.

The node’s GPUs, CPU and memory count toward what the cluster offers tenants from then on. Nothing on the node itself changes.

To take a node out, switch Managed to Off and confirm Take out of pool. Nothing running on the node is stopped. The change is refused when capacity already granted to tenants on this cluster needs the node.

The cluster’s page

The header carries the cluster’s name, its home tag when it is the installation’s own cluster, and a menu with Edit connection and Remove cluster. Under it: Platform, Status, OpenShift or Kubernetes version, Infrastructure, Apps domain and Last discovered.

When the cluster refused the connection, The cluster refused the connection quotes its answer. When it cannot be reached, The cluster cannot be reached right now says the page shows what was discovered when it was last reached.

Nodes

Cluster nodes: Node, Role, GPU type, GPUs, allocatable/total, vCPUs, Memory, Status (Ready, Cordoned or Not ready) and Managed. All and GPU filter the rows; Rediscover runs discovery now.

Expand a row for the node’s hardware: kubelet, OS image, kernel, container runtime, architecture, internal IP, allocatable CPU and memory, pod capacity, and for a GPU node the GPU model, cards, schedulable units, GPU memory, driver, PCI device ID, compute capability, MIG state and slices, and node group.

GPU telemetry

Live figures read through the cluster’s API server from the NVIDIA DCGM exporter, refreshed every 15 seconds:

• tiles for GPUs (with how many are allocated), Avg utilization, VRAM in use and Power draw;
• Cluster GPU utilization, live, a timeline that fills in as history accumulates;
• GPU usage by namespace: Namespace, GPUs, Average utilization, VRAM in use;
• the per-GPU list, with Search GPUs and filters for Node, Partitioning (Whole cards and slices, MIG slices only, Whole cards only) and Namespace. Each GPU shows its utilization, its VRAM, its power and the pod it is bound to, or unallocated.

MIG profiles are named as DCGM reports them. Kubernetes rounds the memory differently, so the same slice appears under GPU partitioning under a slightly different name.

No GPU metrics means nothing answered on the exporter: the DCGM exporter is not running, or the credential lacks pods/proxy.

GPU partitioning

How each MIG-capable card is carved, read from the GPU Operator’s MIG configuration on the cluster, and the place to change it.

The MIG-capable GPU nodes table shows Node, GPU, Cards, Partitioning (All whole, All n partitioned or n of m partitioned), Configuration and State (Applied, Applying, Rebooting or Failed). A Drifted tag marks a node whose MIG layout was changed outside Olympusx AI; Plan saved marks one with a plan waiting.

Repartitioning is off for every cluster until you switch Allow repartitioning on. While it is on, a banner says so. Switch it off when you are done.

To plan and apply a change:

1. Open a node. The board draws each card as it is carved now, with the node’s GPUs, driver, machine type and MIG strategy.
2. Select Plan a change. Pick a profile from the palette, then click a highlighted slot on a card to place it. Olympusx AI checks every placement against what the card’s firmware allows and names any problem: an overlap, a start slot the profile cannot use, more instances than a card holds, or more compute than it has.
3. Read What this plan changes: each changed card now and after, the schedulable capacity before and after, and the workloads the plan stops.
4. Select Save plan. A plan that would leave the cluster unable to honor a tenant’s capacity envelope is refused with This plan takes capacity tenants are entitled to. Save anyway records it with the reason you give in the audit trail.
5. To apply it yourself, Download YAML or Copy the configuration gives you the configuration for the GPU Operator. To apply it from the console, switch Allow repartitioning on, select Apply to the cluster, and confirm Repartition the GPUs.

Repartitioning terminates every process on the affected GPUs

Olympusx AI refuses to apply a plan while any GPU pod runs on the node, and it never evicts one for you. Drain the node first: the page lists everything a drain would also evict, including stateful workloads, and gives you the drain command to copy.

The GPU Operator then stops the device plugin, repartitions the cards and starts everything again, which takes a few minutes. If the node reports a failure, applying again makes the operator retry. Discard saved plan deletes the plan and leaves the node as it is.

Partitioning NVLink-bridged cards disables peer-to-peer traffic across their bridge, so tensor-parallel serving across them falls back to PCIe; the editor warns when a plan does this.

AI/ML workloads

Pods that request GPUs, whole cards or MIG slices: Namespace, Pod, Node, GPU request, Status, VRAM in use and Utilization, refreshed every 15 seconds. Model deployments are listed here, because they run as pods on the cluster.

Namespaces

What each namespace requests against its resource quota, and what it uses live: Namespace, CPU requested, of quota, Memory requested, of quota, GPU, Pods, Storage claimed, of quota and Quota. Hide system namespaces is on by default. Live CPU and memory need the credential’s metrics.k8s.io permission; without it the page says so.

Internet access

Whether pods on this cluster can reach the model source:

• Declared: Air-gapped or Connected, as set when the cluster was registered.
• Measured: Reached the internet, No route out or Never checked, with when it was checked and what the probe saw.

Check now runs a short-lived pod in the namespace imports run in and tries to reach the model source; it takes up to 90 seconds. It measures only. When the measurement disagrees with the declaration, the tab says what that means: a connected cluster that cannot get out will fail its imports after the fetch times out, and an air-gapped cluster that reached the internet has a route out the declaration does not account for.

The declaration is changed through the API, not the console, by sending PUT /api/v1/platform/clusters/<id> with the cluster’s apiUrl and "airGapped": true or false. Fields you leave out keep their values.

Below the measurement, Bastion agent attaches a machine that fetches model weights on this cluster’s behalf. See Remote access.

Registry

The image registry this cluster pulls serving images from. Olympusx AI writes its credential as a pull secret into each namespace where it starts a model server or a runtime inspection on this cluster, so the nodes need no credentials of their own.

To connect one, select Connect a registry, then:

1. Registry address: a host, a port when it is not 443, and a path, such as registry.example.com:5000/olympus. No https://, no tag or digest; each path segment is lowercase letters and digits separated by ., _ or -.
2. Username and Password or token: a pull-only account. Leave both empty for a registry that needs no sign-in. The password is stored encrypted and never shown again.
3. Push username (optional) and Push password or token: lets a job on this cluster copy runtimes into the registry. Only the copy job sees it. Leave empty to copy runtimes by hand.
4. Certificate authority (optional): only when the registry’s certificate is not signed by a public authority. The nodes must trust it too; Olympusx AI uses it to test the connection.
5. Plain HTTP: for an internal mirror without TLS. Credentials are then sent unencrypted.
6. Select Test connection, then Save. Nothing is stored until you save.

People who can edit a project on this cluster can read the pull credential from their namespace, which is why it should be a pull-only account.

The tab then shows the registry’s address, account, certificate authority, push account, last test, and Where the pull secret is installed: each namespace, its purpose (Model serving or Runtime inspection), the deployment that first used it, when it was last written and whether it is Up to date. Changing the credentials rewrites it in every namespace. Remove deletes the address, the stored password and every pull secret; running pods keep their images.

Model weights registry shows, read-only, the registry imported weights are pushed to, which is set at installation for every cluster. See Model registry.

Tenants

Tenants on this cluster: each tenant holding capacity here, with CPU cores, Memory, Storage and GPUs as “used of held”, and Vector databases here. Edit capacity opens the tenant’s capacity on its page.

Edit the connection

1. Open the cluster, then select Edit connection in the header menu.
2. Change API URL, Bearer token, CA certificate or Skip TLS verification. Leave Bearer token blank to keep the stored one.
3. Select Test connection, then Save.

The next discovery uses the new values; nothing restarts.

Remove a cluster

1. Open the cluster, then select Remove cluster in the header menu.
2. Confirm Remove cluster.

Olympusx AI stops tracking the cluster and the nodes discovered on it. Nothing on the cluster itself is changed. Removing a cluster that still has managed nodes is refused: take them out of the pool first.

Limits

Limit	Value
Cluster name	3 to 40 lowercase letters, digits and hyphens; unique
Automatic discovery	Every 5 minutes
Live telemetry, workloads and namespaces	Refreshed every 15 seconds while the tab is open
Internet access check	Up to 90 seconds
Capacity values	0 or more; negative values are refused
Storing a cluster token	Requires the platform’s master key; without it registration is refused with 503 sealer_unconfigured

Related

• Tenants, where capacity envelopes are granted
• Projects, where project quotas are set
• Settings, where GPU flavors are kept
• Model registry and Remote access
• Requirements for supported GPUs and the NVIDIA GPU Operator