If you run Kubernetes inside WSL2, you have probably noticed something odd: your laptop fans spinning, your host crawling, and a process called vmmem eating memory like it is getting paid by the megabyte. The reason is by design, and it is also exactly the part that needs fixing.
Window Subsystem Linux v2 (WSL2) is an iteration of the VM created by Microsoft, from Hyper-V to WSL, and this is the second generation of WSL. If it’s your first time accessing WSL2, it automatically provides you with the default setup which doesn’t provide any limits accessing your full workstation resources (CPU, RAM and other HDD). It means that if you have 8 cores CPU and 16Gb memory, it will use all that up. The problem with it is sometimes it affects your host computer, and it gets slow, and running a Kubernetes cluster inside WSL2 makes it dramatically worse, since each node and container competes with your host for the same pool.
So, to solve that problem we try to limit the resource consumption of WSL2.

Photo by Sadik Brika on Unsplash
⚙️ Limit WSL Resource Consumption
On your profile directory %USERPROFILE% create a new file named .wslconfig. Set its content to the following:
[wsl2]
memory=8GB
processors=8
Change the settings based on your workstation capability, and this is what works for me. If your machine has 16 cores, do not give WSL all 16; leaving the host some breathing room is the entire point of this exercise. The same logic applies to memory: reserve a chunk for Windows and your browser, and give the rest to the VM.
Next, open up a powershell terminal in administrator mode and restart the LxssManager as this manages WSL2:
Get-Service LxssManager | Restart-Service
You could also use the wsl --shutdown method to restart WSL, which is often the more reliable option, since it fully tears down the VM so it can pick up the new limits on the next start. Check if the vmmem process still consumes beyond its limit: open Task Manager and watch its memory column for a minute, and it should now hover around the ceiling you set instead of climbing toward the sky.
🔧 Troubleshoot
If the changes are still not reflecting, try to restart your machine and also restart Docker Desktop. Docker Desktop manages its own WSL distributions, and it is remarkably good at caching old settings until you make it look again. A full reboot clears everything and lets the new .wslconfig take effect without ghosts.
🧠 Final Thoughts
Limiting WSL2 feels counterintuitive at first: why would you want to give your development VM less resources? But a Kubernetes cluster that makes your host unusable is not faster, it is just hungrier. With a sensible cap, WSL2 containers and your desktop coexist peacefully, and the cluster feels snappier precisely because the machine is no longer thrashing.
Set the limits, restart WSL, and enjoy a Kubernetes environment that runs like a tool instead of a resource black hole. Thanks for reading!
