Crater: a Kubernetes control plane for shared GPU clusters

The gap Crater is trying to fill between Kubernetes and a shared GPU service

Kubernetes and Volcano give you scheduling primitives. They do not give you a way to answer who used 400 GPU-hours last month, who is allowed to submit, or which team's notebook is holding a node idle. The README states this directly: operating a shared GPU cluster for many teams still requires a lot of glue, and Crater is positioned as that glue. The comparison table in the README contrasts raw kubectl and YAML access with a web console, CLI and APIs behind role-based multi-tenant access. The intended audience is named too: universities, research institutes, enterprise AI teams and internal platform teams. That is a specific and relatively narrow group. If one person owns the cluster and everyone else is a guest, most of Crater's surface area (accounts, approvals, queues, billing-oriented visibility) is overhead you will pay for without using. The project makes sense when the cluster is a service with consumers who are not cluster operators.

Accounts, queues, quotas and approvals as the actual product

Strip away the UI and the core of Crater is a governance model. The README describes managing users, accounts, queues, quotas, approvals and billing-oriented resource visibility, and says this turns a raw GPU cluster into an accountable shared service. The scheduling side is built on Kubernetes and Volcano and covers queue-based admission, priority-aware execution, prequeue policies and workload placement across heterogeneous resources, including mixed training and serving workloads. The important design consequence is that admission control is a first-class object rather than something you express in a manifest. That matters for mixed training and serving clusters, where a long-running fine-tune and a latency-sensitive inference endpoint compete for the same cards. Crater's answer is queue and priority policy, not a separate cluster per workload type. Whether that is enough depends on how strict your serving SLOs are, and the README does not quantify any of it.

What the repository layout tells you about the architecture

Crater is a Go backend with a React frontend, shipped as a Helm chart. The README links four separate documentation entry points: the Helm chart under charts/crater, a backend README, a frontend README and a CLI README. That split is informative. There is a server component, a browser console, and a command-line client, which means the platform is not purely declarative; you interact with it through its own API surface rather than only through kubectl. The topics list is the clearest statement of what it integrates with: buildkit, nerdctl and envd for image and environment building, Jupyter for interactive development, Ray, PyTorch, TensorFlow and Llama Factory for workloads, vLLM for inference serving, Volcano for scheduling, and Helm for deployment. The README also mentions an AI-assisted operations interface alongside the web console and CLI. Read that as a third access path, not as a replacement for the other two. Nothing in the supplied material describes the internal data model or the API contract, so if you need to integrate Crater into an existing portal, plan to read the backend README rather than rely on this overview.

Getting it running: Helm chart, CLI, and what to check first

The documented installation path is the Helm chart in the charts/crater directory, and the repository has a helm-chart-validate workflow, which suggests the chart is treated as a supported artifact rather than an afterthought. The backend has its own build workflow. Beyond that, the supplied README does not list concrete values.yaml keys, required environment variables or the exact Helm commands, so treat any specific install command as something you must confirm from the chart's own README and the admin documentation at raids-lab.github.io/crater before you run it. The prerequisites you can infer with confidence are a working Kubernetes cluster, Volcano installed as the scheduler layer, NVIDIA GPU nodes, and persistent storage for the managed datasets, models and images the README describes. The CLI is a separate binary with its own README. Two releases are listed, v1.0.0 in April 2026 and v1.1.1 in July 2026, so the project is on a roughly quarterly release cadence at the point of the last push in September 2026.

Where Crater is the wrong tool

Crater assumes Kubernetes. If your workloads run on Slurm, or on a single workstation with two GPUs, or on a managed cloud endpoint where you never touch the scheduler, nothing here applies and the multi-tenant machinery is pure cost. Second, the platform is opinionated about Volcano. Queue-based admission, priority and prequeue policies are Volcano concepts, so a cluster running the default kube-scheduler or a different batch scheduler cannot simply swap Crater in. Third, the integration surface is broad: buildkit, nerdctl, envd, Jupyter, Ray, vLLM, Llama Factory and Volcano all appear in the topics list. Each is a moving part with its own version compatibility. The README does not publish a compatibility matrix, and that absence is the single biggest practical risk for an operator. Fourth, the AI-assisted operations feature is described but not specified; do not plan around it until you have read the admin documentation. Finally, the documentation is bilingual with English and Simplified Chinese, and the README's own documentation link points at the Chinese site path, so verify that the English pages cover the features you depend on.

How it differs from assembling the stack yourself

The obvious alternative is not a competing product; it is the combination of Kubernetes, Volcano and your own tooling. That is what most research clusters actually run today. The difference in approach is where the policy lives. In a DIY stack, quota and fairness are expressed as Volcano queue and podgroup manifests, and the human process around them (who gets an account, who approves a large request) lives in tickets and spreadsheets. Crater moves that process into the platform: accounts, approvals and quotas become objects the system enforces, and the web console is the interface for them. The trade is control for coherence. A DIY stack lets you adopt a new scheduler or a new notebook image without waiting for an upstream release; Crater gives you one workflow across users, images, datasets, models, jobs and services at the cost of a dependency you do not fully control. If your team already has a working internal portal, porting it to Crater is a migration, not an install.

Maintenance, upgrades and the licence

Crater is Apache-2.0, which permits commercial and internal use, modification and redistribution, and includes an explicit patent grant. That is a permissive licence with no copyleft obligation on your own code, but this is not legal advice; if you redistribute a modified Crater or embed it in a product, have counsel review the NOTICE and attribution requirements. Operationally, you inherit the upgrade cost of everything Crater touches. A Kubernetes version bump, a Volcano version bump, or a CUDA/driver change on the GPU nodes can each break part of the stack, and the release history shows two releases across roughly six months, which is a modest cadence. Budget for someone who can read Go, since the backend is the component most likely to need patching when an upstream dependency moves. The Helm chart and the backend build workflow are the two artifacts to watch between releases.

Editorial conclusion

Adopt Crater if you already run Kubernetes and Volcano for a shared GPU cluster and your bottleneck is governance (accounts, queues, quotas, approvals) rather than raw scheduling. Do not adopt it if you want a single-node workstation setup, if you cannot run Volcano, or if you are unwilling to own a Helm release plus a Go backend and React frontend. Before committing, verify three things in your own cluster: which Kubernetes and Volcano versions the chart at charts/crater actually targets, whether the approval and quota model matches how your institution allocates GPU time, and whether the heterogeneous accelerator support covers the specific NVIDIA hardware you have, since the README lists nvidia among its topics but does not enumerate device support.

Official sources

1. License: Apache-2.0
2. Project website
3. raids-lab/crater on GitHub
4. README
5. Releases