Open soootaleb opened 6 years ago
It seems that configuration managers are a good solution to initialize physical machines after OS has been installed
It's a question to ask: Do we aim for VMs provisioning or just go for a server level abstraction ? In other words, do we want to connect VMs or physical servers ?
One question to be asked is simply
Why use OpenStack if Kubernetes is intended to manage cluster of machines ?
Here is an interesting point from this article
Some have viewed VMs as additional unnecessary overhead when running Kubernetes clusters, in favor for running Kubernetes on bare metal servers instead. Typically, in organizations where the service consumer and operator are loosely coupled, in relative terms, it would make sense to run Kubernetes clusters within VMs, to benefit from the strong security segregation of VMs, as well as reliability and resilience afforded by VMs. The greater security, reliability and resilience benefits come at the price of KVM overhead, typically seen as approximately 4 percent of peak system performance. Is 4 percent too high a price to pay? Conversely, in organizations with a tightly coupled relationship between the service consumer and operator, it would viable to run Kubernetes clusters on bare-metal servers to gain better performance, though potentially being exposed in the event of any security glitch or encountering down time in the event of faults in the data center.
This quotes confirms that OpenStack & Kubernetes - whatever we say - can overlap in their role. Of course they're absolutely not the same, neither in their implementation nor their approach. But the question to put a machine-level orchestrator (i.e a way to pop VMs) is a question to ask, without any obvious answer.
Dealing with machine level is the idea of managing physical servers smoothly. This level abstracts the physical machines (x7) and exposes the possibility to create VMs by hundreds. Those VMs will be orchestrated & configured at the next level in #4
Here are potential tools