Hacker News Reader

Comment by old-gregg | Hacker News Reader

Kubernetes has a real chance to succeed where OpenStack failed. Good people at AWS have good reasons to be worried and will push us to a proprietary form of "serverless".

View on HN

OpenStack's failure is that it's an extremely complex system that looks to be nearly impossible to deploy by yourself. You have to use a Distro that does everything for you- their way.

Kubernetes is simple enough to setup yourself. They have well documented tooling, and a solid do it yourself guide. OpenStack has none of that (that I can find). You select RedHat Openstack (RDO) or Canonical OpenStack (MAAS), and you have to use their all-in-one system to have a deployment- and that requires a narrow set of variables which every environment might not have. Which is insane- and will hinder adoption.

EDIT. Not 100% correct, see below comments.

The issue with Kubernetes isn't that it's hard to setup, but it's difficult to keep operate long term. Simple things like balancing workloads across availability-zones is still not trivial.

I've heard many stories of people who tried to run Kubernetes themselves in production and didn't have a great experience for it.

I've been running it in production for stateful workloads for over a year and it's been going swimmingly. I've never had better uptime or efficiency.

You don't have to use a distro. There are well tested puppet modules, which you could make into your own "distro", as well as openstack-ansible and kolla, and openstack-helm which uses helm to deploy openstack. There is also StarlingX. There is no kubeadm like system however, though I'm not sure how many people will really use kubeadm in prod.

Is it complex? Yes. Is it more complex than k8s? Probably. However, are there multiple open source distros outside of RDO (which is not actually a distro and is instead packaging--see tripleo for a distro like solution based on RDO). MaaS is not an OpenStack distro; it's a way to manage baremetal nodes that OpenStack is then deployed onto using other Canonical related tools. That said, selecting a way to deploy and manage openstack is complex, but the same with k8s.

True. My only experience is with VMware OpenStack, and my quick googling didn't turn up much info. I think Kubernetes will fall to the same fate as OpenStack is sliding into. Growing complexity with promises of the world. Time will tell.

You seem to know more than I do, so I got to ask. Why does openstack-helm exist? Why would anyone want to deploy OpenStack on top of kubernetes? Is it so you can have the OpenStack API run in Kubernetes that manages physical boxes?

One of the issues with Openstack is managing the services required to run it. I imagine that helm could be used to make it easier to run these services in kubernetes.

True, but that adds another layer of complexity to an already complex system. If I'm using the ansible module, that's complex enough. Throwing in management of Kubernetes and the additional cruft containers adds- it seems like it's a lot of hassle for little gain.

I see this argument relatively frequently. "Why use Kubernetes when I can accomplish X with [puppet|chef|ansible]".

The answer is that k8s offers something fundamentally different and until the person posing the question gets that distinction, the argument is relatively pointless.

I'm not just bowing behind the argument that "you just don't get it... man". Let me point out that you're right. You can manage the openstack control plane perfectly well with your configuration management tool of choice and if you have that process really dialed, then you'll have a difficult time improving upon it with something like k8s.

Because the OpenStack control plane is made up of many (some required, some optional) services that are basically Python daemons. It makes sense to run them in containers and manage their life cycle...which means it makes perfect sense (to me, and others) to run openstack as an application managed by k8s.

I think they are quite different solutions, and each benefits from the other. Further, they also tend to run into the same concerns at the about the same time in their life time, eg. concerns around complexity.

Reply on news.ycombinator.com