Hacker News Reader

Comment by darren0 | Hacker News Reader

The real reason for these projects (Virlet, KubeVirt, RancherVM) is that OpenStack is too damn hard. Even with all this focus on containers these days people still need an onprem VM solution. But the requirements are really pretty simple for most use cases and the cost and complexity of OpenStack is not justified.

Edit: disclaimer: my company does RancherVM.

View on HN

The reason for this project was that people want to migrate to containers as industry is pushing them forward to it, but - there will always be cases in which "normal" containers will be out of scope - when you will be dependent on piece which is: a) based on other than linux based operating system b) you need a specific linux module which for some reason should not be loaded on host kernel c) you need a hardware separation using virtualization because of security reasons All that can be achieved using "somewhere around" openstack, but what about integration/common interface with other parts of stack? That's the reason why we did Virtlet - to have the same interface for "normal" (docker image based) pods and VMs (hard disk image based), with the same kubectl command, with the same api (so it can be used for deployments, daemonsets, statefulsets and so on), with the same thing configuring networking in whole cluster (CNI, hopefully any of your choice - if it's not working, please fill the bug on GH).

I don't fully buy that explanation. If OpenStack was better they would have already had success on that platform and then would be asking for a bridge between k8s and OpenStack (openstack could easily be a virtual kubelet). Instead people are looking to abandon OpenStack in favor of something hopefully better.

I'm not saying that OpenStack is better/worse - it was only out of our goals. For sure OpenStack has better tenancy support, much more mature approach to networking or storage (in containers world we are still working on https://github.com/container-storage-interface/spec ) but in the same time - we only needed to have a qcow2 based vm running between already deployed pods, with the same user interface. That's all, without other story around that.

Lars from Fuga Cloud here.

We run a public cloud largely based on OpenStack components. While OpenStack can be daunting, using a configuration manager like Ansible makes any kind of deployments a lot simpler and reusable. We use Ansible internally to deploy Kubernetes to deploy new versions of OpenStack.

Tutorial[0] on how to use Ansible in combination with OpenStack.

[0]: https://fuga.cloud/academy/tutorials/deploying-owncloud-on-f...

Reply on news.ycombinator.com