Managed, Self-managed, Cloud, On-premises, VM and Bare Metal
- date
- category
- Containers
- also in
- Cloud · Infrastructure
- reading
- 5 min / 1075 words
To finish, it is worth sorting out a few terms that often show up next to Kubernetes:
- managed Kubernetes,
- self-managed Kubernetes,
- public cloud,
- private cloud,
- on-premises,
- virtual machines,
- bare metal.
The problem is that these terms are often used as if they described the same choice.
They don't.
Each of them answers a different question.
The simplest way is to split the topic into three independent axes:
- Who manages Kubernetes?
- Where does the infrastructure run?
- What do the nodes run on?
Only the combination of these three answers gives the full picture of an environment.
1. Managed vs self-managed: who manages Kubernetes?
This distinction is about responsibility for the Kubernetes platform itself.
Managed Kubernetes
In the managed model the service provider takes over part of the responsibility.
Typical examples are:
- Amazon EKS,
- Azure Kubernetes Service,
- Google Kubernetes Engine.
The provider maintains mainly the control plane and the operational pieces around it.
In practice you don't have to build and maintain everything around:
kube-apiserver,etcd,kube-scheduler,kube-controller-manager,- control plane high availability.
The exact scope depends on the specific service, but the general rule is simple:
managed Kubernetes
-> the provider manages part of the platform
That doesn't mean the provider manages your whole environment, though.
You are still responsible for, among other things:
- workloads,
- access configuration,
- part of the networking,
- resource configuration,
- application security,
- how the cluster is used.
So managed Kubernetes reduces the scope of operational responsibility, but doesn't remove the need to understand the platform.
Self-managed Kubernetes
In the self-managed model you are the one responsible for building and maintaining the cluster.
You can use tools such as:
- kubeadm,
- RKE2,
- Kubespray,
- other distributions and automation systems.
In such an environment the organization is responsible for a much larger scope:
- control plane,
- etcd,
- backups,
- certificates,
- HA,
- upgrades,
- nodes,
- networking,
- integration with the infrastructure.
Put simply:
managed
-> the provider takes part of the responsibility
self-managed
-> responsibility for Kubernetes is on your side
This distinction says nothing yet about where the cluster runs.
2. Public cloud, private cloud and on-premises: where does the infrastructure run?
The second axis is about the environment the machines run in.
Public cloud
Public cloud is infrastructure delivered by an external provider.
Examples:
- AWS,
- Azure,
- Google Cloud.
In the public cloud you can run both managed and self-managed Kubernetes.
A managed example:
AWS
-> EKS
A self-managed example:
AWS
-> EC2
-> kubeadm
In both cases the infrastructure runs in the public cloud.
The difference is who manages the Kubernetes layer.
That is why:
public cloud != managed Kubernetes
On-premises
On-premises means the infrastructure runs in the organization's own environment, most often a private data center or server room.
It can be physical hardware as well as virtualized infrastructure.
Example:
own data center
-> VMware
-> VM
-> Kubernetes
This is on-premises, even though the nodes are virtual machines.
That is why:
on-premises != bare metal
Private cloud
Private cloud is cloud infrastructure dedicated to a single organization.
It can run on-premises and use, for example:
- OpenStack,
- VMware,
- other infrastructure platforms.
Private cloud offers mechanisms similar to the public cloud, but the environment stays private.
Example:
OpenStack
-> VM
-> Kubernetes
In that case you can have all of these at once:
private cloud
+
on-premises
+
self-managed Kubernetes
+
VM
This shows that these terms describe different layers.
3. VM vs bare metal: what does the node run on?
The third axis is about the compute layer.
Virtual Machine
In this model a Kubernetes node is a virtual machine.
The scheme looks more or less like this:
physical server
|
v
hypervisor
|
v
VM
|
v
OS
|
v
Kubernetes node
This is a very popular model.
Nodes can run this way:
- in the public cloud,
- in a private cloud,
- on-premises.
The virtualization layer adds an extra abstraction between Kubernetes and the physical hardware.
It can make easier, among other things:
- provisioning,
- automation,
- resource management,
- isolation,
- quickly creating and removing machines.
Bare metal
Bare metal means the node runs directly on a physical machine.
The scheme:
physical server
|
v
OS
|
v
Kubernetes node
There is no hypervisor and no VM layer here.
Bare metal tends to be chosen where these matter:
- high performance,
- low and predictable latency,
- GPUs,
- specialized networking,
- direct hardware access,
- reusing existing server infrastructure.
At the same time bare metal means more responsibility for the hardware itself:
- provisioning,
- firmware,
- failures,
- replacing disks,
- machine lifecycle.
Most importantly:
bare metal
-> says what the node runs on
It says nothing about who manages Kubernetes.
How these models combine in practice
It is best seen on concrete examples.
EKS
managed Kubernetes
+
public cloud
+
usually VM
The provider maintains the control plane, the infrastructure runs in AWS, and workers usually run as EC2 instances.
Kubernetes on EC2 with kubeadm
self-managed Kubernetes
+
public cloud
+
VM
You still use AWS, but you maintain the control plane and all of Kubernetes yourself.
Kubernetes on VMware in your own data center
self-managed Kubernetes
+
on-premises
+
VM
A local environment, but still virtualized.
Kubernetes on physical servers
self-managed Kubernetes
+
on-premises
+
bare metal
Here Kubernetes runs directly on physical machines.
Comparison
| Example | K8s management | Location | Compute |
|---|---|---|---|
| EKS | managed | public cloud | usually VM |
| AKS | managed | public cloud | usually VM |
| GKE | managed | public cloud | usually VM |
| kubeadm on EC2 | self-managed | public cloud | VM |
| RKE2 on VMware | self-managed | on-premises | VM |
| Kubernetes on physical servers | self-managed | on-premises | bare metal |
This table shows the most important thing:
managed, cloud and bare metal are not three alternatives to each other.
They describe three different decisions.
Common wrong shortcuts
"Bare metal is the opposite of managed Kubernetes"
No.
The opposite of managed is self-managed.
Bare metal is about the compute layer.
"On-premises means bare metal"
No.
On-premises can run on VMware, OpenStack or other VMs.
"Public cloud means managed Kubernetes"
No.
In the public cloud you can run your own self-managed cluster on regular VMs.
"Self-managed means on-premises"
No.
Self-managed Kubernetes can run in AWS, Azure or Google Cloud as well.
How to think about it
Instead of asking:
what type of Kubernetes do we have?
it is better to ask three separate questions.
1. Who manages Kubernetes?
managed
or
self-managed
2. Where does the infrastructure run?
public cloud
private cloud
on-premises
3. What do the nodes run on?
VM
or
bare metal
So a full description of an environment can look like this:
self-managed Kubernetes
+
on-premises
+
bare metal
or:
managed Kubernetes
+
public cloud
+
VM
Only a description like that tells you clearly what kind of environment you are dealing with.
What to remember
The most important distinction is very simple:
managed / self-managed
-> who manages Kubernetes
public cloud / private cloud / on-premises
-> where the infrastructure runs
VM / bare metal
-> what the node runs on
Once these three axes are kept apart, the terms stop getting mixed up and it becomes much easier to compare different ways of running Kubernetes.