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.

Public Cloud Kubernetes Deployment (non-distributed cloud)

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.

On-premises Kubernetes Deployment (non-distributed cloud)

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.

Direct Baremetal Kubernetes Deployment (no hypervisor, non-distributed cloud)

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:

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.

OpenShift Virtualization Deployment

So, there is always one or more baremetals in this architecture as well. In summary, following are the key points:

  1. 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.
  2. 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.
  3. Kubernetes deployment on virtual machines (pervasive adoption) has its sweet spot and business use case.
  4. Kubernetes deployment on baremetals directly have its own sweet spot and business use case.