Kubernetes Requirements

Kubernetes

Version 1.30 or later (validated on 1.30 to 1.32). Linux workers of the CPU architecture named in MANIFEST.txt (amd64 or arm64). No GPU is needed

kubectl version; kubectl get nodes -L kubernetes.io/arch

Access

Permission to create namespaces, CRDs, cluster RBAC, admission webhooks, Secrets, and workloads

Your role and binding review

cert-manager

Installed and healthy, version 1.12 or later, with a working issuer. This is a hard requirement: the operator exits without it. Its startup check detects the cert-manager API only, not the version or the issuer's health

kubectl get pods -n cert-manager; the issuer shows READY=True

Issuer scope

A ClusterIssuer, or an Issuer in minerva-app, where the installation issues the UI certificate

kubectl get clusterissuer, or kubectl -n minerva-app get issuer once the namespace exists

StorageClass

Dynamic provisioning, SSD-backed, ReadWriteOnce, and set as the cluster default

kubectl get sc shows yours marked (default)

Load balancing

A way to expose two Services: the UI (443/TCP) and telemetry (4317, 4318, 9091, and 4319/TCP plus 514/UDP, in one Service with mixed protocols). The operator installs no load balancer. The telemetry endpoint needs raw layer-4 reachability and can't go behind an HTTP ingress

Your load-balancing solution is healthy and has free addresses

Ingress

Optional. An IngressClass and a healthy ingress controller, only if you publish the UI through your own gateway (see Prepare the External Addresses)

kubectl get ingressclass

DNS

A DNS record for your UI hostname

nslookup <ui-hostname> returns the UI Service address or your gateway address

Registry

Reachable from every node, over TLS that the node container runtime trusts. A CA Secret inside the cluster doesn't configure runtime trust

Pull any image from it on a node

Node settings

fs.inotify.max_user_instances set to at least 1024 on every worker, persisted through your node-configuration mechanism; node clocks synchronized

sysctl fs.inotify.max_user_instances; timedatectl

Admission policies

Your policy engine admits this release's workloads, including init containers and nginx. A blanket restricted profile isn't automatically compatible

No denial events during the installation

Keycloak Operator manifests

The five upstream manifest files for Keycloak Operator release 26.7.5, obtained through your normal artifact process (stage them before entering a disconnected environment). The two images they need are already in the archive

Files present

${MINERVA_REGISTRY_URL}

The one repository path that will hold every NVIDIA Minerva image, for example registry.example.com/minerva. Nodes must reach it over TLS their container runtime trusts

All three files

${MINERVA_PLATFORM_VERSION}

The platform release from MANIFEST.txt, for example 1.1.0

Infrastructure and application

${MINERVA_STORAGE_CLASS}

Your dynamic, SSD-backed, ReadWriteOnce StorageClass, for example gp3. It must also be the cluster default, because the identity database always uses the default class

Infrastructure and application

${MINERVA_UI_HOSTNAME}

Your UI hostname, the one address users open, for example minerva.example.com. Sign-in runs under the same address, so the identity and application files take the same value

Identity and application

${MINERVA_ALLOWED_CIDRS}

The source networks allowed in, for example 10.0.0.0/8. It appears twice in the application file: under spec.nginx.service for browsers, and under the gateway-push collector for devices. The two values may differ

Application, twice

${MINERVA_CUSTOMER_NAME}

A display name, for example Example Corp

Application

${MINERVA_CLUSTER_NAME}

A display name, for example prod-eu-1

Application

${MINERVA_OIDC_ISSUER_URL}

Only if you federate login to your identity provider: your provider's issuer URL. Otherwise, leave the block commented out

Identity, commented block

${MINERVA_OIDC_CLIENT_ID}

Only if you federate login to your identity provider: the client ID you created in your provider

Identity, commented block