YEyebyen·Nov 11, 2018
I think that's poignant. The example that comes to mind is SAP: their dev teams embraced both, OpenStack and K8S, culminating in this glorious monstrosity[1] called openstack-helm, by which you could run Kubernetes on bare metal nodes, then deploy OpenStack on top of that, and finally running Kubernetes on those virtual machines again.
The idea being that if your customers need Kubernetes clusters, you should be able to provision them on-demand from elastic resources.
This seems like a great approach, since you can pick a layer to apply redundancy at, and only apply it there. You do not need a triple-redundant control plane built on a redundant backplane, if you are confident in the redundancy of the backplane. I am not a customer of SAP but I am a fan of many complex uses of Helm, and this seemed like it had been very well-considered
Read the rest
application of the tool.
Anyway learning about this implementation left me with a slightly dirty feeling that I was idolizing a Rube Goldberg level of complexity system that didn't need to be so complicated.
Then I heard about Gardener[2], which solves the same problem without OpenStack at all. Seed clusters create shoot clusters, with their control planes deployed inside namespaces of the seed cluster. There's no virtualization overhead, and you get all of the same benefits in terms of supervision. Also from SAP. I hope I get to work with something like this.
[1]: https://github.com/sapcc/openstack-helm
[2]: https://gardener.cloud/