Epic: Windows worker restoration

[wizpresso-steve-cy-fan]

Seems like this is much more complicated than I think. There are several things we need to fix before it is working again.

First step is to let kubelet/kube-proxy run correctly on Windows worker again, this is an ongoing issue under investigation.

Next step should be adding back the missing Dockershim altogether. We could either use:

cri-dockerd: https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/

Directly use containerd in Windows. We already have a scoop bucket available: https://github.com/rivy/scoop.bucket.scoop-main/blob/master/containerd.json

The first method should work out of the box with Mirantis and Docker Desktop with minimal changes, while the latter will be more formal and correct but will require significantly more code changes than former, relatively speaking of course.

Notice: you can just install Docker Engine on Windows with chocolatey. It will support Windows Container mode only, however. But this opens the door for most Windows 10 to run k0s.

Related

#2460
#2567

[wizpresso-steve-cy-fan]

/remove-stale

[twz123]

The main problem with Windows support is missing CI coverage. So IMO the first step would be to tackle that. In the process of adding the coverage, all the regressions compared to k0s 1.23 could be fixed (e.g. #2460 and potentially other things). That would bring us back to the state of k0s 1.23. That'd be the baseline for any other improvements.

Concerning CI: We could try to hack on some (probably ugly) GH workflow that tries to bring up a Windows worker somehow on a GH Windows runner and see how far we get with that. Looking at the OS of the runners that execute the Windows unit tests (Microsoft Windows Server 2022 10.0.20348), it should be possible to run Windows containers on those.

[wizpresso-steve-cy-fan]

/remove-stale