Networking Minerva User Guide
Networking Minerva User Guide
Breadcrumbs

Kubernetes Installation

NVIDIA Minerva can be installed on a Kubernetes cluster that you own and operate. The NVIDIA Minerva operator, installed with Helm, deploys and manages the complete platform from three custom resources that you configure.

One Installation, Both Stacks

The reference configuration deploys the complete NVIDIA Minerva deployment in your cluster:

  • The Platform Stack: storage and messaging, identity (login), and the analytics services and UI.

  • The Collector Stack: the collectors that receive telemetry from your devices.

Both stacks run in the same cluster under the same operator, and the collectors write into the platform's messaging layer there, so the installation always deploys the two together. You can't mix deployment methods: collectors installed with Docker Swarm can't connect to a Kubernetes platform, and collectors installed on Kubernetes can't connect to a Docker Swarm platform.

How It Works

The operator runs in the namespace minerva-system and manages three custom resources, one per tier. Each tier's workloads run in their own namespace:

Custom resource

Workloads run in

What it deploys

MinervaInfra

minerva-infra

Storage and messaging: Kafka, MySQL, Neo4j, Druid and its object store, BlobDB, Consul, Redis, and log collection

MinervaIdentity

minerva-identity

Identity: a dedicated Keycloak and its database, which provide login. This resource is cluster-scoped, and there is exactly one, named cluster-identity

MinervaApp

minerva-app

The analytics services, the UI and its HTTPS front door, the license service, and the collectors

In the reference configuration, the application tier doesn't start until identity is ready, so the operator enforces the installation order itself. Applying the resources one at a time, as these pages do, makes a failure easier to attribute to one tier.

What NVIDIA Delivers

NVIDIA delivers a release archive built for one CPU architecture. It contains:

  • the minerva-operator Helm chart

  • every container image the installation needs, as a docker-save archive, with an image list

  • three reference custom resources, one per tier

  • MANIFEST.txt, which names the platform release, the operator version, and the CPU architecture

  • the installation guide (README.md)

  • open-source license attribution and the written offer for the corresponding source

No NVIDIA endpoint is needed at any point, so the installation also works in a disconnected environment.

What You Provide and Operate

You provide the cluster and everything on it that isn't NVIDIA Minerva: cert-manager, the upstream Keycloak Operator, storage, your container registry, load balancing, DNS, certificates, node configuration, and optionally an ingress controller and your corporate identity provider. These pages state exactly what each of them must provide and how to check it. Install and operate them by following your own platform's procedures. Where these pages show an example manifest for one of them, it's illustrative.

Who Installs and Uses It

  • Not tenant-specific. Running NVIDIA Minerva on Kubernetes is a property of the whole installation, decided when the platform is installed. It isn't enabled, disabled, or licensed per tenant.

  • Who installs and operates it: your Kubernetes administrators. The installation needs permission to create namespaces, CRDs, cluster RBAC, and admission webhooks (see Cluster Requirements). Later changes are made by editing and applying the custom resources, which also needs cluster access. NVIDIA Minerva users don't need any Kubernetes access.

  • Who uses it: interactive users sign in through the platform's identity service and work in the NVIDIA Minerva UI. The base installation provides local user accounts, managed by the platform's built-in Keycloak, starting with a default administrator account. You can also federate login to your corporate OIDC identity provider. Both are covered in Validate and Sign In. Tenants, users, and roles (Platform Admin, Tenant Admin, Editor, and Viewer) work as in any NVIDIA Minerva installation (see Configure Tenants and Manage Users and Roles).

  • What's available: every tenant of an installation is served by the same components. A component that the reference configuration doesn't enable (see Scope of This Release) isn't available to any tenant of that installation. The license applies to the whole installation. While the license state is expired or invalid, most user-facing features are unavailable to all users, while signing in and viewing the license state remain available. Data collection and processing continue (see Manage Licenses).

Scope of This Release

  • The procedure covers a new installation. It doesn't cover moving data from an existing NVIDIA Minerva installation.

  • The reference configuration is a complete functional installation. It isn't a high-availability topology.

  • Each archive is built for one CPU architecture, amd64 or arm64, named in MANIFEST.txt.

  • The reference configuration enables the AI agent and its read-only MCP servers (Druid and Neo4j), with a dedicated Redis instance for the agent. Generative AI stays off until a Platform Admin configures and enables it in the UI. The NFP model (GPU inference) isn't enabled. The NVIDIA Minerva CLI pod is off by default (see The NVIDIA Minerva CLI).

  • The optional collectors (WJH, host metrics, cluster state, and Prometheus scraping) are off by default. You can turn them on when you configure the custom resources (see Configure the Custom Resources).

  • High-frequency telemetry (HFT), NVLink management, and NMX-C integration aren't included yet.

Last updated: