> ## Documentation Index
> Fetch the complete documentation index at: https://hyperbolic.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Managed Kubernetes

> A Kubernetes cluster on your GPU instances, with the control plane run by Hyperbolic

> [!NOTE]
>
> Managed Kubernetes is in **beta**. It works, teams are running on it, and the surface is still changing. Expect the feature list below to grow, and tell us what's missing.

Managed Kubernetes gives you a ready-to-use GPU Kubernetes cluster without running a control plane yourself. You choose the GPU nodes; Hyperbolic provisions the cluster, installs the NVIDIA stack, and gives you a single sign-on kubeconfig that authenticates `kubectl` as **you**.

## What you get

* **A hosted control plane**, run and kept available by Hyperbolic, located in a cloud region close to your GPU nodes.
* **GPU worker nodes** that are your rented instances — same hardware, same networking, same billing as renting them directly.
* **NVIDIA GPU Operator and Network Operator** preinstalled, so GPUs, drivers, and RDMA networking are exposed to pods on day one.
* **Single sign-on access.** You download a per-cluster kubeconfig; the first `kubectl` command signs you in through Hyperbolic in your browser and authenticates as **you** — short-lived, with every action attributed to your identity instead of a shared admin credential. Org admins get `cluster-admin`; other members get `edit`. RBAC inside the cluster is yours to extend. See [Connect with kubectl](https://hyperbolic.ai/docs/managed-kubernetes/kubectl-access.md).
* **Multi-node performance without overhead.** NCCL all-reduce inside a pod matches the same test run on the bare host.

## Create a cluster

1. In the console, open **Kubernetes**. The launch wizard opens. You can also reach it from **Launch Cluster** in the sidebar.
2. Pick the GPU type, node count, and region, then select **Launch cluster**. Nodes in one cluster are in the same region and on the same interconnect.
3. Wait for the cluster to show **Ready**. The progress view shows each provisioning stage: Hyperbolic provisions the worker nodes, joins them to the cluster, and installs the add-ons. The cluster dashboard opens as soon as the cluster is Ready. GPU and health tiles show "telemetry warming up" until the nodes start reporting.
4. Install the `kubectl oidc-login` plugin (one-time) and select **Download kubeconfig** in the **Connect with kubectl** section of the **Cluster info** card. It's also in the cluster actions menu (**⋮**) — see [Connect with kubectl](https://hyperbolic.ai/docs/managed-kubernetes/kubectl-access.md) for the install commands. Then point `kubectl` at the file:

```bash theme={null}
export KUBECONFIG=~/Downloads/hyperbolic-cluster.yaml
kubectl get nodes -o wide
```

The first command opens your browser to sign in with Hyperbolic; after that, `kubectl` runs as you. You should see one node per GPU instance, each advertising `nvidia.com/gpu` capacity.

> [!TIP]
>
> You can still rent interconnected multi-node clusters **without** Kubernetes — see [On-Demand](https://hyperbolic.ai/docs/on-demand/overview.md). Managed Kubernetes is one way to run on those nodes, not the only way. If you already run a cluster, [Rental Operator](https://hyperbolic.ai/docs/rental-operator/overview.md) (beta) rents GPUs from it as Kubernetes resources.

## Node pools

Nodes are grouped into pools. From the cluster's **Pools** tab you can see each pool's GPU type, size, and status, and add or remove nodes. CPU-only worker pools for non-GPU workloads (proxies, monitoring, controllers) are on the roadmap.

## Running GPU workloads

Request GPUs like any other resource:

```yaml theme={null}
resources:
  limits:
    nvidia.com/gpu: 8
```

For multi-node training, the Network Operator exposes the RDMA interfaces to pods; use your framework's usual NCCL launcher. The NCCL and interconnect checks in [Verifying Instance Performance](https://hyperbolic.ai/docs/on-demand/verifying-performance.md) apply unchanged inside Kubernetes.

## Exposing services

Nodes have public IPs. A `NodePort` or `hostNetwork` service is reachable from the internet only once the port is open on the node — see [Opening inbound ports](https://hyperbolic.ai/docs/on-demand/storage-and-ports.md#opening-inbound-ports). Prefer an in-cluster ingress plus one open port over exposing many NodePorts.

## Storage

Node-local NVMe is available to pods as `hostPath` or a local volume and does **not** survive node replacement. Shared network storage for clusters is in development; until it ships, use your own object storage for checkpoints.

## Monitoring

The cluster page in the console shows the pods and events on each node and live GPU telemetry. You are free to install Prometheus, Grafana, or any observability agent in the cluster. A fuller **Monitoring** tab with history is in development.

## What Hyperbolic runs, and what you run

| Hyperbolic | You |
| - | - |
| Control plane availability and upgrades | Everything scheduled on the cluster |
| Node provisioning, GPU drivers, add-on installation at bootstrap | RBAC, namespaces, network policy |
| Single sign-on — authenticating users as themselves, short-lived | RBAC bindings for your own teams and service accounts |
| Node replacement on hardware failure | Add-on configuration after bootstrap — if you modify or remove an add-on, that's the new state |
| Platform telemetry | Application monitoring, logging, alerting |

Managed Slurm is on the roadmap; Kubernetes is the supported orchestration path today.

## Terminate a cluster

Open the cluster from **My Clusters**, then go to the **Settings** tab and select **Terminate** in the **Danger zone**. You can also select **Terminate** from the cluster actions menu (**⋮**). Terminating tears down the control plane and releases every node. Billing stops, and nothing on the cluster is recoverable.

In an organization, only the member who created the cluster or an org admin can terminate it. Other members see a message in place of the **Terminate** button.

Terminated clusters appear under **Past clusters** on the **My Clusters** page. Each entry shows the cluster's final name and the actual amount charged.

## Email notifications

Hyperbolic emails your account contacts at key points in a cluster's lifecycle:

| Email | When it's sent |
| - | - |
| Launching | Hyperbolic accepted your cluster request and started building it. |
| Ready | The cluster reported **Ready** for the first time and billing started. |
| Taking longer than expected | The cluster is still building after about 40 minutes. Sent once. |
| Provisioning failed | The cluster couldn't finish bring-up and was torn down without charge. |
| Control plane unreachable | Hyperbolic can't reach the cluster's control plane. Sent once per outage. |
| Balance warning | Your balance is running low and the cluster will be terminated when it runs out. |
| Terminated | A member of your account terminated the cluster. |
| Terminated for zero balance | Hyperbolic terminated the cluster because your account balance reached zero. |

## Billing

GPU nodes are billed exactly like the same instances rented directly. The hosted control plane is billed separately and shown on the cluster's billing tab.

Clusters draw from your account balance like on-demand instances. When your balance runs low, Hyperbolic sends a balance warning for each running cluster. If your balance reaches zero, Hyperbolic terminates the cluster. Configure [Auto Top-Up](https://hyperbolic.ai/docs/general/auto-top-up.md) to avoid losing a cluster to an empty balance.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.