Userspace networking had been around for quite a few years, yet didn't seem to have taken off, despite all the great benchmarks... I think the main blocker is that you cannot make apps use it without hacks. It looks like Snap requires a custom library that probably doesn't even have to implement BSD sockets, since that's something you don't have to care about at Google.
Some years ago I recall looking into this, and it looked kernel had limitations in higher speed ethernet (must had been 50GbE at the time), and it came down to single-threaded nature of the TCP/IP stack in the kernel at the time. So that's been one of the drivers for experiments in userspace. Looks like that might now be the case now [1], but if someone has more specific info I'd be quite curious to hear.
There a few minor UX flaws that make it frustrating to use, e.g. having to set Docker host, shared filesystem performance is poor, networking in enterprise desktop environment is broken (just to name a few top most issues).
Also, a lot of folks end up running Docker for Mac and minikube VMs, why should they have to run two VMs?
Additionally, minikube is completely different from production-grade deployments (single binary, which means a rewrite of main function for etcd and all control plane components, as well as hard to debug basic performance issues in control plane, there is one large process and you don't know what is wrong, also there is no way to use your favourite network add-on).
Additionally, minikube is based on legacy Docker libmachine, it is not really maintained anymore.
It will be possible to run all your add-ons in the local setup, including networking. Multi-node is essential for some use-case, but arguably is not critical for most people, yet it is coming in the future.
At Weaveworks, we have a built a tool called Flux [1]. It is able to relate manifests in a git repo to images in container registry. It has a CLI client (for use in CI scripts or from developer's workstation), it also has an API server and an in-cluster component, as well as GUI (part of Weave Cloud [2]).
Flux is OSS [3], and we use it to deploy our commercial product, Weave Cloud, itself which runs on Kubernetes.
Right, if you know how to set it up or have infrastructure in place... But most developers don't have time to read 600+ pages on how to run bind server OR simply have ops team that is very conservative at what goes in the DNS land.
Well, adding a library for supporting SRV records is not simple... If you use Weave [1], it gives a unique IP address to every service instance and a DNS record, all with zero configuration. That means you just stick any service in whatever default port it has, and it's all good. You can also have round-robin load balancing through DNS for free.
The exact approach described here is very extreme. It's a top-down method with a tool. I find the tool may be of some interest, but I think bottom-up method would be more practical . I have done some experiments with Yocto/OpenEmbedded and about to put that out one day, once I have time to document it ...
Some years ago I recall looking into this, and it looked kernel had limitations in higher speed ethernet (must had been 50GbE at the time), and it came down to single-threaded nature of the TCP/IP stack in the kernel at the time. So that's been one of the drivers for experiments in userspace. Looks like that might now be the case now [1], but if someone has more specific info I'd be quite curious to hear.
[1]: https://www.phoronix.com/scan.php?page=news_item&px=Broadcom...