Guest post by Vishal Anand, Utpal Mangla, and Luca Marchi, IBM
Kubernetes never existed without Baremetals !! If we say that, it would not be incorrect for enterprises at all. It is of no surprise that some of the personas have not been able to realize that fact. Not that, they need to but knowledge is the currency. And, our intention here is to explain just that with real world scenarios.
We will talk about the special place that baremetal holds in various (and all) deployment models of Kubernetes.
In Fig.1 below, it is the persona B and C who have been predominantly using Containers and Kubernetes for years now. For ease of consumption, their perspective about the cluster is something (most of the time) which runs on virtual machines because they do not need to see or know or touch the underlying infrastructure.
Cloud providers (Persona A) take care of the underlying infrastructure and even the control plane of the Kubernetes clusters (e.g. masters, etc.). However, there is always one or more baremetals in this architecture.
In Fig. 2 below, which is the on-premises deployment where a lot of responsibilities lie with the owner’s organization. However, there is always one or more baremetals in this Kubernetes deployment architecture as well.
In Fig. 3, Kubernetes cluster is directly deployed on top of baremetals. It could be in any landing zone and the responsibility matrix would be the same or mixed or shared depending upon the deployment scenarios like the above two. This architecture has tremendous advantages in terms of latency, performance etc.
Companies estimate that the Total cost of ownership savings for deploying Kubernetes on a bare metal compared to a virtualized infrastructure could be as high as 30 percent, depending on application and configuration.
Above deployment has the following advantages:
- With the elimination of the virtualization layer, the infrastructure overhead is drastically reduced. More compute and storage resources are now available for application deployments thereby increasing hardware efficiency. This is especially important for edge computing, which often have resource constraints in remote sites.
- Application performance is better and more deterministic on bare metal deployments since bottlenecks like the guest operating system and virtual switches are removed with the virtualization layer.
- Introduction of new hardware acceleration technologies like smart NICs (Network Interface Cards) and support for GPUs (Graphics Processing Units), needed for very demanding applications become easier for new 5G use cases.
In Fig. 4, one of the technologies which enables declarative co-existence by bringing mixed workloads on a common Kubernetes platform. That also requires baremetal for production environment (and support) to run VMs and containers side by side.
So, there is always one or more baremetals in this architecture as well. In summary, following are the key points:
- There is always a baremetal (or more) for Kubernetes deployments across enterprises. It all depends on who you are i.e. which persona you are playing, which privileges or restrictions you like to exercise.
- Various personas do not need to know or do anything about baremetals as long as worker nodes (compute) are required as virtual machines to run containerized workloads.
- Kubernetes deployment on virtual machines (pervasive adoption) has its sweet spot and business use case.
- Kubernetes deployment on baremetals directly have its own sweet spot and business use case.