Managed, self-managed, cloud, on-premises, VM i bare metal - Blog

Na koniec warto uporządkować kilka pojęć, które często pojawiają się obok Kubernetes:

managed Kubernetes,
self-managed Kubernetes,
public cloud,
private cloud,
on-premises,
virtual machines,
bare metal.

Problem w tym, że te określenia często są używane tak, jakby opisywały ten sam wybór.

Nie opisują.

Każde z nich odpowiada na inne pytanie.

Najprościej rozbić temat na trzy niezależne osie:

Kto zarządza Kubernetes?
Gdzie działa infrastruktura?
Na czym działają nody?

Dopiero połączenie tych trzech odpowiedzi daje pełny obraz środowiska.

1. Managed vs self-managed: kto zarządza Kubernetes?

To rozróżnienie dotyczy odpowiedzialności za samą platformę Kubernetes.

Managed Kubernetes

W modelu managed część odpowiedzialności przejmuje dostawca usługi.

Typowe przykłady to:

Amazon EKS,
Azure Kubernetes Service,
Google Kubernetes Engine.

Provider utrzymuje przede wszystkim control plane i związane z nim elementy operacyjne.

W praktyce nie musisz samodzielnie budować i utrzymywać wszystkiego wokół:

kube-apiserver,
etcd,
kube-scheduler,
kube-controller-manager,
wysokiej dostępności control plane.

Dokładny zakres zależy od konkretnej usługi, ale ogólna zasada jest prosta:

text

managed Kubernetes
-> częścią platformy zarządza provider

Nie oznacza to jednak, że provider zarządza całym Twoim środowiskiem.

Nadal odpowiadasz m.in. za:

workloady,
konfigurację dostępu,
część networkingu,
konfigurację zasobów,
bezpieczeństwo aplikacji,
sposób wykorzystania klastra.

Managed Kubernetes zmniejsza więc zakres odpowiedzialności operacyjnej, ale nie usuwa potrzeby rozumienia platformy.

Self-managed Kubernetes

W modelu self-managed to Ty odpowiadasz za zbudowanie i utrzymanie klastra.

Możesz użyć narzędzi takich jak:

kubeadm,
RKE2,
Kubespray,
innych dystrybucji i systemów automatyzacji.

W takim środowisku organizacja odpowiada za dużo większy zakres:

control plane,
etcd,
backupy,
certyfikaty,
HA,
upgrade'y,
nody,
networking,
integrację z infrastrukturą.

Najprościej:

text

managed
-> provider bierze część odpowiedzialności

self-managed
-> odpowiedzialność za Kubernetes jest po Twojej stronie

To rozróżnienie nie mówi jeszcze nic o tym, gdzie klaster działa.

2. Public cloud, private cloud i on-premises: gdzie działa infrastruktura?

Druga oś dotyczy środowiska, w którym uruchomione są maszyny.

Public cloud

Public cloud to infrastruktura dostarczana przez zewnętrznego providera.

Przykłady:

AWS,
Azure,
Google Cloud.

W public cloud możesz uruchomić zarówno managed, jak i self-managed Kubernetes.

Przykład managed:

text

AWS
-> EKS

Przykład self-managed:

text

AWS
-> EC2
-> kubeadm

W obu przypadkach infrastruktura działa w public cloud.

Różnica polega na tym, kto zarządza warstwą Kubernetes.

Dlatego:

text

public cloud != managed Kubernetes

On-premises

On-premises oznacza, że infrastruktura działa we własnym środowisku organizacji, najczęściej w prywatnym data center lub serwerowni.

Może to być zarówno fizyczny hardware, jak i infrastruktura zwirtualizowana.

Przykład:

text

własne data center
-> VMware
-> VM
-> Kubernetes

To jest on-premises, mimo że nody są maszynami wirtualnymi.

Dlatego:

text

on-premises != bare metal

Private cloud

Private cloud to infrastruktura cloudowa przeznaczona dla jednej organizacji.

Może działać on-premises i korzystać np. z:

OpenStack,
VMware,
innych platform infrastrukturalnych.

Private cloud daje mechanizmy podobne do public cloud, ale środowisko pozostaje prywatne.

Przykład:

text

OpenStack
-> VM
-> Kubernetes

W takim przypadku można mieć jednocześnie:

text

private cloud
+
on-premises
+
self-managed Kubernetes
+
VM

To pokazuje, że te pojęcia opisują różne warstwy.

3. VM vs bare metal: na czym działa node?

Trzecia oś dotyczy warstwy compute.

Virtual Machine

W tym modelu node Kubernetes jest maszyną wirtualną.

Schemat wygląda mniej więcej tak:

text

physical server
   |
   v
hypervisor
   |
   v
VM
   |
   v
OS
   |
   v
Kubernetes node

To bardzo popularny model.

W ten sposób mogą działać nody:

w public cloud,
w private cloud,
on-premises.

Warstwa wirtualizacji daje dodatkową abstrakcję pomiędzy Kubernetes a fizycznym sprzętem.

Może ułatwiać m.in.:

provisioning,
automatyzację,
zarządzanie zasobami,
izolację,
szybkie tworzenie i usuwanie maszyn.

Bare metal

Bare metal oznacza, że node działa bezpośrednio na fizycznej maszynie.

Schemat:

text

physical server
   |
   v
OS
   |
   v
Kubernetes node

Nie ma tutaj hypervisora i warstwy VM.

Bare metal bywa wybierany tam, gdzie ważne są:

wysoka wydajność,
niskie i przewidywalne opóźnienia,
GPU,
specjalistyczny networking,
bezpośredni dostęp do hardware,
wykorzystanie istniejącej infrastruktury serwerowej.

Jednocześnie bare metal oznacza większą odpowiedzialność za sam sprzęt:

provisioning,
firmware,
awarie,
wymianę dysków,
cykl życia maszyn.

Najważniejsze:

text

bare metal
-> mówi na czym działa node

Nie mówi nic o tym, kto zarządza Kubernetes.

Jak te modele łączą się w praktyce?

Najlepiej zobaczyć to na konkretnych przykładach.

EKS

text

managed Kubernetes
+
public cloud
+
zwykle VM

Provider utrzymuje control plane, infrastruktura działa w AWS, a workery zwykle są uruchamiane jako instancje EC2.

Kubernetes na EC2 z kubeadm

text

self-managed Kubernetes
+
public cloud
+
VM

Nadal korzystasz z AWS, ale control plane i cały Kubernetes utrzymujesz sam.

Kubernetes na VMware we własnym data center

text

self-managed Kubernetes
+
on-premises
+
VM

To środowisko lokalne, ale nadal zwirtualizowane.

Kubernetes na fizycznych serwerach

text

self-managed Kubernetes
+
on-premises
+
bare metal

Tutaj Kubernetes działa bezpośrednio na fizycznych maszynach.

Porównanie

Przykład	Zarządzanie K8s	Lokalizacja	Compute
EKS	managed	public cloud	zwykle VM
AKS	managed	public cloud	zwykle VM
GKE	managed	public cloud	zwykle VM
kubeadm na EC2	self-managed	public cloud	VM
RKE2 na VMware	self-managed	on-premises	VM
Kubernetes na fizycznych serwerach	self-managed	on-premises	bare metal

Ta tabela pokazuje najważniejszą rzecz:

managed, cloud i bare metal nie są trzema alternatywami dla siebie.

Opisują trzy różne decyzje.

Typowe błędne skróty myślowe

"Bare metal to przeciwieństwo managed Kubernetes"

Nie.

Przeciwieństwem managed jest self-managed.

Bare metal mówi o warstwie compute.

"On-premises oznacza bare metal"

Nie.

On-premises może działać na VMware, OpenStack albo innych VM.

"Public cloud oznacza managed Kubernetes"

Nie.

W public cloud możesz uruchomić własny self-managed klaster na zwykłych VM.

"Self-managed oznacza on-premises"

Nie.

Self-managed Kubernetes może działać również w AWS, Azure albo Google Cloud.

Jak o tym myśleć

Zamiast pytać:

jaki typ Kubernetes mamy?

lepiej zadać trzy osobne pytania.

1. Kto zarządza Kubernetes?

text

managed
czy
self-managed

2. Gdzie działa infrastruktura?

text

public cloud
private cloud
on-premises

3. Na czym działają nody?

text

VM
czy
bare metal

Przykładowy pełny opis środowiska może więc wyglądać tak:

text

self-managed Kubernetes
+
on-premises
+
bare metal

albo:

text

managed Kubernetes
+
public cloud
+
VM

Dopiero taki opis mówi jasno, z jakim środowiskiem mamy do czynienia.

Co zapamiętać

Najważniejsze rozróżnienie jest bardzo proste:

text

managed / self-managed
-> kto zarządza Kubernetes

public cloud / private cloud / on-premises
-> gdzie działa infrastruktura

VM / bare metal
-> na czym działa node

Jeżeli te trzy osie są rozdzielone, pojęcia przestają się mieszać i dużo łatwiej porównywać różne sposoby uruchamiania Kubernetes.