Remove support for Windows

[thomastaylor312]

In #702 we discussed the possibility of removing support for Windows. This is primarily for two reasons:

1. We adopted "feral code" from the internet to make things work. This has forced us to shim in a super old version of tokio (because the things the adopted code uses no longer exist in the public API of tokio) that now has some bad vulnerabilities
2. In practice, we haven't seen people actually using this in Windows for Real Things™

Number 1 can eventually be addressed when there is better support for UnixStream and UnixListener for windows. UDS support does exist in Windows itself, but because Rust supports versions of Windows older than Windows 10, they don't have those structs in Windows.

So if we choose to go this way, there will be two important details. First, this is a major breaking change. This is acceptable under the guidelines we sent out for the alpha series releases of 1.0, but we will need to communicate this well. Second, we will need to create an issue for adding Windows support back in.

If you are a Krustlet (or kubelet crate) user doing something on Windows PLEASE LET US KNOW. The last thing we want to do is unintentionally screw things up for someone doing something real with Windows

[RaananHadar]

I humbly wanted to provide some reasons against this breaking change:

Some may say that these are niche reasons in the era of the cloud. But I think these 2 reasons are both very common AND very important for users that work on on-prem enterprise networks:

1. In many Enterprises, there are many users who can't use WSL due to organization policy as many organizations don't support hyper-v on developer machines. By losing windows support, krustlet loses a unique but important advantage of enabling local k8s development for such users. I'm thinking about being able to run k3s on windows with krustlet for example, which cannot be done today effectively.
2. Most enterprises have a large on-prem cluster of bare-metal windows server machines lying around. Right now their best bet to put them to good use is to use something like Hashicorp's nomad for the windows machines and k8s for the linux machines. Having different orchestration tools is definitely harder and being able to use everything with k8s is very beneficial.

These reasons are actually the main reason why I am looking for krustlet as a project.

Lastly, wasm is about being able to run your code everywhere. So shouldn't k8s follow suit? I really like this project either way, and I really hope you consider this 🙏

[bacongobbler]

I understand where you're coming from, @RaananHadar. But the question was more about who is either developing or running Krustlet on Windows. We understand the benefits. But right now the issues stemming from Windows support is actively preventing us from shipping 1.0 due to the issues mentioned earlier. So we're trying to gauge how much interest there is in attempting to fix this (which will cause further delays to 1.0's release) or we remove Windows support for now and re-introduce in a future update when things stabilize.

I'm +1 on removing support for now and re-introducing it in a future update.

[RaananHadar]

I'm all for shipping 1.0 and fully understand that you can't support everything from the get go.

I just wanted to make sure that you understand that that this is a viable use case and re-introduce this as part of the roadmap and not permanently remove this from the scope of the project.

[bacongobbler]

ACK. That was always part of the plan :)

Second, we will need to create an issue for adding Windows support back in.