January 13, 2023

How to run microk8s on your WSL Ubuntu 22.04?

You probably have your own reasons why to run microk8s, for me it started with finding a way to try out Cilium. I wanted an easy and resource optimal solution, also something that is not limited to development use cases and allows for occasional deep dive. Easy, right? Well, now it is ๐Ÿ˜‰

Before we start

Make sure you are running at least version 0.67.6 of WSL, which is the first one that comes with systemd support out of the box, required for everything we are about to do. If you are unsure simply run wsl -v

We will also run all the commands as an Administrator / root. You can become root with sudo -s command.

Most of you probably already have WSL installed, but in case you don’t you can quickly get it directly from Microsoft Store for Windows 10/11.

Configuring WSL

Now we need to enable systemd, which will allow us to use snap and install microk8s. We do that by editing /etc/wsl.conf and configuring its boot section. WSL’s hostname defaults to Windows’s hostname, which can cause trouble due to invalid characters, so we set it explicitly to something simple.

touch /etc/startup.sh
nano /etc/wsl.conf # CTRL+O to save, CTRL+X to exit



Once we are done with that, we have to restart our WSL instance to make the changes effective.

wsl --terminate Ubuntu-22.04

Let’s verify if our wsl.conf file is actually loaded by comparing the hostname seen in the terminal with the one from configuration. If it doesn’t match, try restarting WSL again, this time waiting few seconds more.

Installing microk8s

The company behind both Ubuntu and Microk8s is Canonical, so as expected installation experience is pretty smooth, but not without hiccups ๐Ÿ™‚ Here is the official installation guide from them.

Turns out, that before we start the installation we have to switch to iptables-legacy, as unfortunately it doesn’t seem to be well supported at the moment and microk8s doesn’t even start with iptables-nft with an error “microk8s is not running. Use microk8s inspect for a deeper inspection.”. This is despite release notes for v1.21 saying ‘Update to support distributions with iptables-nft’.

update-alternatives --set iptables /usr/sbin/iptables-legacy

# installs v1.26 at the time of writing
snap install microk8s --classic

And that’s it! Just like that we have a fresh running microk8s cluster inside of our WSL. This is awesome, as we can now use “Zero-ops, pure-upstream Kubernetes, from developer workstations to production.”. Maybe a first small step towards replacing Docker Desktop completely?

Before we finish, let’s verify if all is up by running the following commands:

microk8s version
microk8s status
microk8s kubectl get all --all-namespaces

In case something doesn’t work as expected, we need to troubleshoot with microk8s inspect and analyze the logs. kubectl logs can also come in handy to figure out why some pods are not getting ready.

At this point user experience is still far from perfect as we might struggle with the most basic tasks like following how to…

  • connect from a host machine with kubectl?
  • connect from a host to our Load Balancers, Node Ports, Ingresses?
  • efficiently reach Ingress by hostname, unique for each service?
  • run multiple nodes in our dev environment?
  • change the default CNI?
  • anything you might be wondering about… please comment!

But for now… let future us handle it ๐Ÿ˜‰

Why did we choose microk8s on WSL?

First obvious choice is to look at Docker Desktop and its build-in Kubernetes. This works great when we are all about deploying applications. Unfortunately turns out is is nearly impossible to customize (CNI, CSI, missing systemd, you just get what you get) – so we are giving up on that one.

Second obvious choice is to utilize Windows Subsystem for Linux. WSL comes with great Windows Terminal integration and some port forwarding magic that make overall experience appealing. We have plenty tools to choose from, most popular ones being k3s, k3d, kind, minikube, and microk8s. They can run on bare metal, virtual machine or even within docker.

Last but not least, we prefer not to run VM on Hyper-V or Virtual Box for our primary node. This sounds rather heavy, and just doesn’t feel right in 2023, unless absolutely necessary. Luckily we have avoided it so far.

Long story short, as we wanted simple, pure and lightweight – microk8s is the most appealing one to me. I believe it will allow us to deep dive into Kubernetes when we want to, while keeping overall day to day experience smooth. It is also a big plus that it potentially can run everywhere and has support of a leading vendor, so we invest time into something that we can utilize in other projects.