I'm planning a small training cluster where each student gets an isolated environment with their own namespace, ResourceQuota, and LimitRange. Students should be able to start their environment on demand, keep their work on a per-student persistent volume, and have the overall cluster monitored.
I currently have two Windows machines on the same LAN: a 16 GB desktop and an 8 GB laptop. My initial plan was to run a single k3s cluster with the desktop as the server/control-plane node and the laptop as an agent.
I'm new to Kubernetes and would like to know whether Windows is practical for this. Would I need Linux installed directly on one or both machines, or would Linux VMs or WSL2 be reliable enough? I'd also appreciate suggestions for the overall setup and storage approach.
4 Answers
k3s is lightweight, but Windows is not a straightforward native platform for it. WSL2 can work, though its NAT-based networking often makes communication between the control plane and a remote agent awkward. You may also run into issues with DNS, load balancing, and storage.
For something intended to be dependable, I’d use lightweight Linux VMs on both Windows machines, or install Linux directly if that’s an option. The desktop could give a VM roughly 10–12 GB of memory and the laptop 5–6 GB. Namespaces, ResourceQuota, and LimitRange are appropriate for student isolation. k3s’s local-path provisioner can handle basic persistent volumes, while Prometheus and Grafana are reasonable monitoring choices for a small lab.
Hyper-V is probably the easiest route if you want to keep Windows on the machines. Create small Ubuntu Server VMs and bootstrap the cluster there. You could use kubeadm, but k3s will usually require less memory and fewer moving parts for this project.
If the machines can be dedicated to the lab, replacing Windows with a lightweight Linux installation will give Kubernetes more usable resources. Either way, make sure the VM or host networking allows the agent to reach the control plane directly.
If this is mainly for experimentation rather than a production-like service, you could run a local Kubernetes distribution on the desktop, such as Minikube or a desktop Kubernetes environment. That is easier to start with, but it won’t give you the same experience as a real two-node cluster, and persistent storage across the two physical machines may be awkward.
For a shared student service, I’d first test the namespace and quota model on one Linux VM, then add the second node and persistent storage once the basic workflow works. With only two nodes, avoid depending on complex distributed storage unless you really need it; a simple local volume or an NFS share may be easier to operate.
Two machines with 24 GB of RAM total will be quite limited for anything beyond a small class. You can build a useful lab, but leave plenty of headroom for the operating systems, Kubernetes components, monitoring, storage, and student workloads.
A simpler design may be to give each student a browser-based development environment and a lightweight virtual cluster, rather than trying to provide a large shared cluster. That keeps tools and Kubernetes versions consistent and lets students work through a browser. For a very small setup, though, a pair of Linux VMs running k3s is much more practical than trying to manage Kubernetes directly through WSL2.
That makes sense for larger training sessions, but I’m starting with a very small lab. I’ll probably keep the first version simple with Linux VMs and avoid adding per-student virtual clusters until I understand the basics.