nvke is a management plane for running managed Kubernetes on your own NVIDIA GPU hardware, and its original repository sits at 984 stars. The Chinese translation, published 2026-11-09 at yangshun2005/nvke-cn, is a fresh fork with no stars yet. What it offers is not new code but a fully translated README plus a short Chinese quick-start guide that the original does not have.

The project language is Go, and it is licensed under Apache-2.0.

What NVKE actually is

The name expands to NVIDIA Kubernetes Engine. It is not a Kubernetes distribution and not a variant of Cluster API. The README is explicit about this: NVKE provides a management plane that platform teams install, and from that plane they create and operate separate Kubernetes clusters for their customers. Each workload cluster gets its own Kubernetes control plane, its own etcd, and its own node pools.

So the unit of delivery is a cluster per customer, not a namespace per customer. You run the NVKE management plane. Your customers reach their clusters through the Kubernetes API and kubectl.

That distinction matters when you compare it to multi-tenancy approaches built on virtual clusters or namespace isolation. Here the isolation boundary is a real control plane and a real etcd.

The preview status is not a footnote

The README puts a blockquote near the top: NVKE is available as a preview. APIs, configuration, and behavior may change between releases, and the project does not recommend running production workloads on it.

The Chinese version keeps that warning and adds a section of practical caveats. Several of them are worth repeating because they affect how you would plan an evaluation:

  • After installation, API authentication is off by default and the API speaks plain HTTP. Before letting any caller connect, you need to configure authentication and protected access following docs/operate/api-authentication.md.
  • The management cluster does not upgrade, scale, or replace itself. There is no management-plane upgrade procedure and no backup or restore flow.
  • The FDE node images are for evaluation only and do not provide data-at-rest confidentiality.
  • In the preview, NVIDIA Infra Controller (NICo) is the only compatible infrastructure provider. A real installation requires access to it.

None of these are hidden in the original English docs, but they are scattered across several files. The Chinese quick-start collects them in one place, which is the main reason the translation is useful beyond language.

Trying it without GPU hardware

The lowest-friction path does not need a GPU or an NVIDIA account. The local quickstart at docs/get-started/quickstart-local.md runs a development management plane and a workload cluster on simulated machines.

Hardware requirements for that path, per the README:

  • Linux host or VM, amd64 or arm64
  • At least 6 CPUs
  • 12 GiB of free memory
  • 100 GiB of free disk
  • Virtual TPM support
  • Docker installed

macOS users are routed to docs/get-started/local-site.md, which runs the evaluation inside a Colima VM. The node agent only runs on Linux, so there is no native macOS path.

The goal of the quickstart is concrete: get through setup until you have created a workload cluster and confirmed its nodes report Ready.

Building from source

Two toolchain requirements come up immediately. The README states Go 1.27.3 and GNU Make 4 or later. There is a discrepancy worth knowing about: docs/getting-started.md says Go 1.26+, while go.work pins the exact version. The Chinese guide tells you to trust go.work.

git clone https://github.com/dsx-ai-factory/nvke.git cd nvke make build

The build produces nine binaries under bin/, including agent, updater, controller, and nvkectl. It does not start the management plane and does not create any cluster. That surprises people who expect make build to leave them with something running.

For module-level work, the getting-started doc lists per-module commands, for example:

make -C controller build

The macOS Make trap

This is the kind of detail that costs an afternoon. macOS ships GNU Make 3.81. The build fails outright against it. The fix is:

brew install make

Then call gmake instead of make. Skipping Make and invoking go build directly is not a reliable workaround either, because a toolchain version mismatch can cause a panic.

The Chinese guide calls this out as a known pitfall rather than leaving it to be discovered. For developers in China there is a second network-level issue: the first build needs to reach a public Go module proxy, and the guide notes that a mirror may be required.

Installing for real

A real installation is a different exercise. You supply the machines, the network, the node images, and the image registry, and you configure access to NICo.

The README lays out the sequence across three documents:

  1. docs/operate/plan-installation.md — prerequisites and the order of operations: prepare nodes, bootstrap the management cluster, install services.
  2. docs/operate/bootstrap-management-cluster.md — bootstrapping the management cluster itself.
  3. deploy/README.md — installing the NVKE services.

docs/overview/supported-platforms.md lists verified combinations and pinned dependencies, which is where you should check before committing hardware.

What the management plane does

From the README's feature list, the two core operations are:

  • Create independent workload clusters. You request a cluster through the NVKE API or nvkectl. NVKE provisions machines through NICo and assembles Kubernetes clusters that each have their own control plane.
  • Manage workload cluster lifecycle. Creation and scaling are listed; the README excerpt cuts off there, so treat the lifecycle surface as something to verify against the current docs rather than assume.

The nvkectl CLI is the operator-facing tool. If you have used other cluster lifecycle tooling, the shape will be familiar: declarative requests, a controller reconciling toward them, and a CLI for the common operations.

Why a Chinese translation is worth a repository

The original documentation is thorough. It is also spread across docs/get-started/, docs/operate/, docs/overview/, and deploy/, and the warnings that matter most are distributed among them. For a Chinese-speaking platform engineer evaluating NVKE, the cost is not reading English. It is reading four documents to assemble a mental model before touching a terminal.

The translation addresses that in two layers, and the README is honest about the split:

  • The body is a translation of the original README, aiming to stay faithful to the source.
  • The "中文快速上手" section at the top is supplementary and explicitly marked as not part of the original. It exists so you can get the project running without reading the full README first.

That second layer is where the practical value sits. It covers what the project is and what problem it solves, a five-step shortest path from clone to running cluster, the environment requirements in one list, and the pitfalls section described above. The translation also states that inaccuracies should be reported as issues or pull requests, which is the right posture for a translated technical document.

One caveat on my side: I have read the translated README and the quick-start, but I have not run the local quickstart end to end on my own hardware, so I cannot vouch for whether the 6 CPU / 12 GiB / 100 GiB figures are comfortable or merely sufficient.

Who should look at this

If you operate GPU infrastructure and the question "how do we hand each team or customer an isolated Kubernetes cluster" is on your roadmap, NVKE is worth an evaluation. The preview status means evaluation, not adoption.

If you are a Chinese-speaking engineer on that evaluation, start with the Chinese version. Read the quick-start, run the local path on a Linux box, and only then open the original English docs for depth. The translated repository is at https://github.com/yangshun2005/nvke-cn, and the original is at dsx-ai-factory/nvke.

Chinese documentation: https://github.com/yangshun2005/nvke-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.