|
| 1 | +# Overview |
| 2 | + |
| 3 | +metal-stack is a software to provide physical servers on demand. It is a fully-automated provisioning framework for bare metal machines. To categorize this product, we commonly use the terminology _metal-as-a-service (MaaS)_ or _bare metal cloud_. |
| 4 | + |
| 5 | +```@index |
| 6 | +``` |
| 7 | + |
| 8 | +## Use-Cases |
| 9 | + |
| 10 | +The major intent to initiate metal-stack was to build a framework that provides [Kubernetes](https://kubernetes.io/) (K8s) as a service (KaaS) in on-premise environments. |
| 11 | + |
| 12 | +Running this on-premise has several benefits: |
| 13 | + |
| 14 | +- Data sovereignty |
| 15 | +- Better price/performance ratio |
| 16 | +- Easier connectivity to existing company networks |
| 17 | + |
| 18 | +From the very beginning, the machines provided by metal-stack are provided with the intention to run software managed by K8s. Reason for this is that K8s makes the bare metal approach shine and mitigates the problems that come with the approach (see [Why bare metal?](#why-bare-metal)). |
| 19 | + |
| 20 | +metal-stack itself is typically deployed on Kubernetes as well. However, there are no specific dependencies of metal-stack running in a Kubernetes cluster. It exposes a traditional REST API that can be used for managing bare metal machines. |
| 21 | + |
| 22 | +## Why Do You Need a Cloud? |
| 23 | + |
| 24 | +We are clearly aiming at a fully-automated lifecycle for K8s clusters. The speed in which we want to provide K8s to a user makes this product very attractive. The time saving compared to providing machines and Kubernetes by hand are significant. We actually want to be able to compete with offers of public cloud providers, especially regarding speed and usability. |
| 25 | + |
| 26 | +## Why Bare Metal? |
| 27 | + |
| 28 | +The bare metal approach is especially attractive for the purpose of running K8s on top of it. Bare metal has several advantages over virtualized environments and overcomes several of the drawbacks of virtual machines. |
| 29 | + |
| 30 | +1. Virtual environment drawbacks |
| 31 | + - [Spectre and Meltdown](https://meltdownattack.com/) can only be mitigated with a "cluster per tenant" approach |
| 32 | + - Missing isolation of multi-tenant change impacts |
| 33 | + - Licensing restrictions |
| 34 | + - "Noisy-neighbor" issues |
| 35 | + |
| 36 | +2. Advantages of a metal-as-a-service platform |
| 37 | + - High and guaranteed performance (especially disk i/o) |
| 38 | + - Reduced stack depth (Host -> VM -> Application vs. Host -> Container) => reduced attack surface, cost/performance gain, no VM live-migrations |
| 39 | + - No need for a central storage system: Local storage governed by K8s to reduce storage costs |
| 40 | + - Bigger hardware configuration possible (hypervisors have restrictions, e.g. it is not possible to assign all CPUs to a single VM) |
| 41 | + - K8s ships with "enterprise" features (performance, availability, scalability) on commodity hardware |
| 42 | + |
| 43 | +Beside these benefits there are also several disadvantages of metal-as-a-service platforms to consider: |
| 44 | + |
| 45 | +- Hardware defects have direct impact (should be considered by design) and can not be mitigated by live-migration as in virtual environments |
| 46 | +- Not many "providers" to choose from |
| 47 | +- Bare metal provisioning is slower than provisioning a VM |
| 48 | +- Capacity planning is more difficult (no resource overbooking possible) |
| 49 | +- Higher "AfA"-costs |
| 50 | + |
| 51 | +In the end, we have come to the conclusion that most of the drawbacks of bare metal machines can be mitigated when running K8s on the machines. K8s will take care of high-availability in case of hardware failures and also supervises machine resources. We are certain that the chosen approach can satisfy the needs of the future users to a higher degree than virtual machines could do. |
| 52 | + |
| 53 | +## Roadmap |
| 54 | + |
| 55 | +Coming soon. |
0 commit comments