Kubiverse: Explore Your Kubernetes Cluster as a Voxel World

What would a Kubernetes cluster look like if you could walk through it?

Kubiverse turns namespaces, workloads, pods, and nodes into a pixel-art 3D world. You can explore a simulated cluster in your browser, then connect the same interface to a real cluster through a local bridge.

Here is the teaser:

Try Kubiverse in your browser — no signup or Kubernetes cluster required for the demo.

A cluster you can walk through

The default world is a factory. Kubernetes resources have a place in that world, and their visual state reflects what is happening in the cluster.

A workload's assembly line has a lamp for each replica, and its conveyor belt runs when replicas are ready. Failing pods affect the hall's lights and can produce smoke and fire. In the energy room, you can see which pods are running on each node.

The visual model also extends inside a pod. Containers appear as capsules in a shared fish tank: water represents their shared network, memory usage changes the level inside a capsule, and CPU activity drives a propeller. You can inspect the details behind those visual cues.

Start with a simulated cluster

The start screen offers four scenarios:

• First Steps: two nodes and a small application, for getting comfortable with the controls.
• Online Shop: a broader tour with multiple namespaces and some problems to investigate.
• Incident Day: a failed node and crashing workloads.
• Big Cluster: 15 nodes and a few hundred pods.

For a first visit, choose First Steps. Move with WASD or the arrow keys, click an object to inspect it, and press J to open missions. Once you are comfortable, try Incident Day and follow the problems through the world.

The demo runs against simulated state. You can explore failures and recovery without connecting credentials or changing real infrastructure.

Keep the Kubernetes concepts visible

The missions connect each activity to an explanation and its equivalent kubectl command. The interface includes inspectors, logs, events, a terminal, and a YAML editor, so the resource details remain available alongside the world.

For example, a Pending pod is more than a visual warning: its inspector can show the scheduler's reason, such as insufficient CPU or an untolerated taint. A Service's loading dock shows its connections to pods, making it possible to explore the relationship between the abstraction and the resources behind it.

How it connects to a real cluster

Kubiverse has two main components:

• Godot and GDScript render the world and provide the interface. The same project exports to the browser through WebAssembly and to macOS, Linux, and Windows.
• kubiverse-bridge, written in Go, uses Kubernetes client-go and informers to watch cluster resources. It communicates with the game through HTTP and WebSocket.

The connection looks like this:

Kubiverse ↔ local Go bridge ↔ Kubernetes API server

The bridge uses your kubeconfig, keeping Kubernetes authentication on the bridge host. It can also serve the web build locally, so the game and bridge share an origin.

The repository README covers installation and connection options. Native applications and bridge downloads are available on the releases page.

The demo and a real cluster behave differently

When connected to a real cluster, operations such as scaling a workload, restarting it, or deleting a pod affect real Kubernetes resources.

Kubiverse distinguishes sandbox and production contexts. Production changes require confirmation, while the bridge's --readonly option restricts mutating operations. Kubernetes permissions still matter: use a kubeconfig with access appropriate to what you want to do.

For a first experiment, the browser demo is the easiest starting point. For a first real connection, use a disposable development cluster or read-only access.

Try it and tell me what you think

You can explore the live demo and browse the code and documentation on GitHub.

I would love to hear which Kubernetes relationships are easier to understand this way, where the visual metaphor becomes confusing, and what you would want to inspect next.

Would you use a world like this for learning Kubernetes, explaining a cluster to a teammate, or exploring your own development environment?