Kubernetes without the legwork: x0 in five demos

When we introduced x0 in A lighter foundation for Kubernetes, we walked through the architecture: Kubernetes controllers and workers running as lightweight, hardware-isolated microVMs, with x0 owning the lifecycle around them.

Architecture only tells part of the story, so this time we want to show you x0 actually working. First, a quick look at the problem it solves.

Why microVMs, and the legwork x0 removes

k0s and k3s did a lot to make Kubernetes itself simpler. They package the control plane, kubelet, and container runtime into a compact distribution with far fewer moving parts. But a lightweight distribution does not make the machines underneath it any lighter. Before the first pod is scheduled, someone still has to do the legwork:

• Provision a machine for every controller and worker, either a physical server or a VM on yet another virtualization platform
• Install, harden, and patch an operating system on each of those machines
• Assign addresses and hostnames, and open the ports the nodes need to reach each other
• Set up SSH or another remote access path to every node
• Install the same pinned Kubernetes version on every machine and keep it consistent
• Generate join tokens and move them safely to each new node
• Pre-stage container images for sites without Internet access
• Install and configure a CSI driver so workloads can get persistent storage
• Collect kubeconfig files and hand out cluster credentials to operators
• Repeat all of it for the next cluster, and again whenever a node fails

x0 turns that list into a request. Each Kubernetes controller and worker runs as a lightweight microVM on Starlight, booted from a signed, versioned node image that already carries the Kubernetes distribution, its container runtime, and the images needed for offline operation. x0 decides where each node should run, creates the microVM, delivers enrollment credentials scoped to that specific machine, joins it to the cluster, and applies the required networking and security controls. Nodes are managed through a narrow guest channel instead of general-purpose SSH, operators reach the cluster through x0 with short-lived credentials, and s0 handles persistent storage.

MicroVMs are what make that practical. Each node gets its own kernel behind a hardware virtualization boundary, so a compromised worker does not share a kernel with the Starlight host, and there is no heavyweight virtualization management platform to buy, secure, and patch underneath the cluster. Because nodes are workloads rather than servers, several can share one host, a failed node can be replaced elsewhere, and a new cluster does not start with a hardware order.

The demos

Below are five short recordings taken straight from the terminal. Each one uses x0ctl, the x0 command line, alongside s0, which connects Kubernetes storage requests to the underlying storage provider. Together they cover the complete operational path: create a cluster, give it persistent storage, move between clusters, deploy and scale an application, and inspect the result from a single terminal interface.

Demo 1: build a Kubernetes cluster

x0 creates a new k0s Kubernetes cluster with one dedicated controller and one worker.

x0ctl submits the cluster request, waits for both machines to become ready, and displays their assigned roles. The controller runs the Kubernetes control plane, while the worker runs application workloads. The final view confirms that both machines are healthy through x0.

Why it matters: x0 provisions an entire Kubernetes environment from a single request, instead of requiring an administrator to assemble nodes by hand.

Demo 2: provision persistent storage

Next, we create Kubernetes storage backed by s0 and look at the resulting PersistentVolumeClaim, PersistentVolume, and storage attachment.

A Kubernetes workload requests storage through a PersistentVolumeClaim. The s0 CSI driver provisions the volume, Kubernetes binds it to a PersistentVolume, and the demo confirms that the volume is healthy and available to the application by reading data back from inside the pod.

Why it matters: applications need storage that survives pod replacement and movement. s0 connects Kubernetes storage requests to the underlying storage provider, while x0 provides a unified, read-only operational view of what was provisioned.

Demo 3: switch between cluster contexts

Here, x0ctl switches the active context between an application cluster and a storage-enabled cluster.

x0ctl context use changes the selected cluster, and the shell prompt immediately shows the active cluster and namespace. Commands are then routed through x0 to the selected Kubernetes API using short-lived credentials.

Why it matters: operators may manage many independent Kubernetes clusters. Context switching lets them work naturally without repeatedly supplying cluster IDs or manually managing kubeconfig files.

Demo 4: deploy and scale an application

With a cluster selected, we deploy an application, wait for it to become ready, and scale it from one replica to two.

x0ctl kube passes ordinary Kubernetes operations through x0 to the selected cluster. The demo applies a deployment manifest, verifies the rollout, scales the deployment, and confirms that both application pods are Running.

Why it matters: cluster creation is only useful if applications can be operated normally afterward. x0 supports the Kubernetes workflows your team already knows, without asking anyone to abandon standard Kubernetes commands.

Demo 5: explore storage in the x0 TUI

Finally, we open the x0 terminal interface and look at the selected cluster's Kubernetes storage resources.

The demo selects the storage cluster and its application namespace, opens x0ctl tui, and navigates to the Kubernetes storage view. From there it shows the s0 StorageClass, the bound PersistentVolumeClaim, the PersistentVolume, capacity, freshness, the relationships between them, and detailed health information.

Why it matters: operators need a quick way to understand cluster and storage health without assembling information from multiple tools. The TUI brings x0, Kubernetes, and s0 observations into one navigable interface.

The full path, end to end

Taken together, these demos cover the operational path from start to finish: create a cluster, provision storage, switch between environments, deploy applications, scale workloads, and inspect the platform from a unified interface.

Through all of it, Kubernetes stays Kubernetes. The commands after x0ctl kube are the same ones your team runs today. What changes is the infrastructure underneath.

Next up: x0 in the Starlight UI

The command line is home for many platform teams, but it is not the only way to operate x0. In our next post, we will show x0 in the Starlight UI, so you can see how the same platform looks for operators who prefer a graphical console.

Want a closer look at x0? Talk with Mainsail about Kubernetes microVMs for your environment, or read how x0 works under the hood in A lighter foundation for Kubernetes.