Kubernetes Cluster Playground
A multi-node Kubernetes cluster provisioned with kubeadm, allowing you to choose your preferred container runtime and networking plugin. Perfect for CKA, CKAD, and CKS preparation.

About This Playground
Want to practice kubeadm, compare container runtimes, experiment with different networking plugins, or prepare for the CKA, CKAD, or CKS exam?
iximiuz Labs' Kubernetes playground gives you a ready-to-use, multi-node cluster running on four Linux servers: a dedicated development machine, one control-plane node, and two worker nodes. Before starting it, you can choose the container runtime—containerd or CRI-O—and the networking setup—Flannel, Cilium, or no pre-installed CNI at all.
This is not a simulated cluster or a lightweight Kubernetes distribution with most decisions already made for you. The nodes are lightweight but fully fledged VMs running on iximiuz Labs' bare-metal infrastructure, and the cluster itself is provisioned with kubeadm. Every machine has its own kernel, root filesystem, and network interface, giving you the same kind of access you'd have when administering Kubernetes on cloud VMs or bare-metal servers.
Use this playground for learning Kubernetes administration, testing manifests and Helm charts, practicing upgrades and node maintenance, troubleshooting control-plane and worker components, and exploring the boundary between Kubernetes and its container runtime or networking layer. Switch between containerd and CRI-O, compare Flannel and Cilium, or start without a CNI plugin and install one yourself.
The dedicated development machine comes in handy for operating the cluster without logging directly into its nodes. From there, you can use kubectl, copy files, run diagnostic tools, and interact with the cluster much like you would from an administrator's workstation.
If you start the playground without a networking plugin, the cluster will not have functional Pod networking until you install and configure a CNI plugin yourself. This is useful for learning, but it also means some Pods may remain pending or unready in the meantime.
As with all iximiuz Labs playgrounds, the cluster is not intended for production workloads or services that must stay online indefinitely.
For everything else, start the cluster and get your hands dirty. Drain a node, break the CNI, inspect the runtime, renew a certificate, or misconfigure a workload—then troubleshoot your way back to a healthy cluster. That's how Kubernetes administration becomes a skill rather than a collection of memorized commands.
Happy hacking!
A real VM, not a container
Get root on a VM with its own kernel, so Docker, Kubernetes, and systemd just work.
Read the docs →
SSH from browser or CLI
Use the built-in web terminal, or connect with labctl ssh, plain ssh, scp, or rsync.
Read the docs →
Drive it with AI
Let Claude, Codex, or any MCP client start this playground and run commands in it.
Read the docs →
Expose HTTP(S) ports
Give any web app running inside the VM a public URL - for yourself or to share with others.
Read the docs →
Share terminals
Invite others into your terminal session, or open it yourself from another device.
Read the docs →
Customize with init scripts
Add shell scripts that run at boot to install packages, clone repos, or seed test data.
Read the docs →
Private networking
VMs reach the internet via NAT with no public IP; several VMs share bridge networks.
Read the docs →
Ephemeral or persistent
By default, VMs are destroyed when the session ends; enable persistence to keep the disks for next time.
Read the docs →
Built-in container registry
A private registry.iximiuz.com for every playground to share images across services and VMs.
Read the docs →