Container-Orchestrierung: Kubernetes auf Bare Metal

Jeder verwaltete Kubernetes-Dienst, EKS, GKE, AKS, läuft auf Bare-Metal-Hardware. Die Steuerungsebene läuft auf physischer Hardware. Deine Worker-Knoten sind entweder virtuelle Maschinen, die Teile von physischen Servern nutzen, oder Bare-Metal-Instanzen, die die VM-Ebene komplett weglassen. Der Wert des verwalteten Dienstes liegt in der Automatisierung der Steuerungsebene und der Integration in das Ökosystem, nicht in irgendwelchen grundlegenden Infrastrukturvorteilen.

Wenn du K8s auf InMotion Bare-Metal- oder dedizierten Servern laufen lässt, laufen deine Pods direkt auf der physischen Hardware ohne Hypervisor-Overhead, mit vorhersehbarem NVMe für persistente Volumes und zu festen monatlichen Kosten, die nicht von Node-Stunden oder API-Aufrufvolumen abhängen.

Das Hypervisor-Overhead-Problem in Cloud K8s

Cloud Kubernetes-Worker-Knoten sind virtuelle Maschinen. KVM, Xen oder Hyper-V sitzen zwischen deinen Containern und der physischen Hardware. Das bringt zwei Leistungseinbußen mit sich, die Bare Metal vermeidet:

• CPU-Overhead: Hypervisoren verursachen normalerweise einen CPU-Overhead von 5 bis 15 % für Systemaufrufe und Kontextwechsel. Bei Workloads mit vielen Systemaufrufen (netzwerkintensive Dienste, I/O-gebundene Anwendungen) ist das eine spürbare Verzögerung.
• Speicher-Overhead: Hypervisoren haben ihre eigenen Speicherstrukturen neben dem VM-Speicher. Ein Cloud-Worker-Knoten mit 16 GB hat nach dem Overhead für Hypervisor und Gastbetriebssystem weniger als 16 GB für Kubernetes-Systemkomponenten und Pods.

Auf Bare-Metal-Hardware gibt ein 192-GB-Server Kubernetes die vollen 192 GB, abzüglich des Overheads des Betriebssystem-Kernels (etwa 2–4 GB). Jedes GB der Knotenkapazität ist echt, nicht nur nominell.

Cluster-Architektur-Optionen

Single-Node-K8s für Entwicklung und Staging

Ein einzelner InMotion Hosting , auf dem k3s oder kubeadm mit kombinierten Master- und Worker-Rollen läuft, ist eine praktische Staging-Umgebung. k3s ist hier besonders gut geeignet: Es läuft mit einer produktionsreifen Kubernetes-Distribution mit einer einzigen Binärdatei, SQLite (oder externem etcd für HA) und einem minimalen Speicherbedarf, sodass mehr Ressourcen für Workloads übrig bleiben.

K8s mit nur einem Knoten ist nicht so toll für Workloads, die eine hohe Verfügbarkeit brauchen (ein Knotenausfall legt alles lahm), aber es ist super, um Produktionskonfigurationen in der Staging-Umgebung zu spiegeln, ohne für mehrere Server zu bezahlen.

Produktionscluster mit mehreren Knoten

Ein Kubernetes-Cluster braucht mindestens drei Control-Plane-Knoten für das etcd-Quorum. In der Praxis nutzen viele Teams einen dedizierten Control-Plane-Server und zwei bis drei Worker-Knoten. Mit dedizierten Servern von InMotion:

• Steuerungsebene: Advanced-Tarif (149,99 $/Monat), 64 GB RAM reichen für K8s-Steuerungskomponenten auf Clustern mit weniger als 100 Knoten
• Arbeitsknoten: Extreme-Tier (349,99 $/Monat) pro Arbeiter für speicherintensive Aufgaben; Essential oder Advanced für weniger anspruchsvolle Pod-Profile
• Netzwerk: 10-Gbit/s-Port auf Worker-Knoten für den Datenverkehr zwischen Pods in Service-Meshes mit hohem Durchsatz

Pod-Dichteplanung auf 192 GB / 16-Core-Hardware

Die Pod-Dichte von Kubernetes hängt von den Ressourcenanforderungen und -beschränkungen ab, die in den Pod-Spezifikationen festgelegt sind. Ein grober Planungsrahmen:

Pod-Profil	CPU-Anforderung	Speicheranforderung	Pods pro 192-GB-Knoten
Mikroservice (typisch)	100m	256 MB	~600 Pods (speichergebunden)
Webanwendungs-Pod	250m	512 MB	~300 Pods (speichergebunden)
API-Service-Pod	500m	1GB	~160 Pods (speichergebunden)
Datenbank-Sidecar / Operator	1 Kern	4GB	~40 Pods (speichergebunden)

In der Praxis reserviert Kubernetes Ressourcen für System-Pods (kube-system-Namespace), das Betriebssystem des Knotens und Eviction-Headroom. Der zuweisbare Speicher auf einem 192-GB-Knoten liegt nach diesen Reservierungen normalerweise bei etwa 175 bis 180 GB. Die oben genannten Zahlen sind theoretische Maximalwerte; echte Cluster laufen mit 60 bis 70 % der maximalen Dichte, um Scheduling-Headroom zu haben.

Die 16-Kern-EPYC-CPU schafft locker die Pod-Planung von bis zu 500 aktiv laufenden Pods, bevor die CPU zum Engpass wird. Die meisten echten Cluster mit 100 bis 300 Pods kommen nicht mal annähernd an diese Grenze ran.

Speicher: Persistente Volumes auf NVMe

Lokaler Pfad-Provisioner

Die einfachste Art, persistente Volumes für Single-Node- oder Per-Node-Speicher einzurichten, ist mit dem Local-Path-Provisioner (von Rancher gepflegt, standardmäßig in k3s enthalten). Damit werden PersistentVolumeClaims erstellt, die durch Verzeichnisse auf dem NVMe des Nodes unterstützt werden.

Für Workloads, die keinen Speicher brauchen, um Knotenausfälle zu überstehen (zustandslose Anwendungen mit externen Datenbanken, Jobs, die Scratch-Speicherplatz nutzen), NVMe Local-Path auf NVMe den bestmöglichen Speicherdurchsatz ohne Netzwerk-Overhead. Ein PostgreSQL auf Local-Path NVMe genauso wie PostgreSQL direkt auf demselben NVMe PostgreSQL .

Longhorn für replizierten Speicher

Longhorn (auch von Rancher) ist eine Cloud-native Speicherlösung, die Volumes über mehrere Cluster-Knoten repliziert. Bei Clustern mit mehreren Knoten, bei denen die Pod-Planung unabhängig von der Speicherplatzierung sein sollte, repliziert Longhorn PVC-Daten auf zwei oder drei Knoten.

Der Replikationsaufwand bei NVMe okay: Der Datenpfad von Longhorn sorgt für etwa 10 bis 20 % mehr Latenz im Vergleich zum lokalen Pfad, ist aber immer noch schneller als Cloud-Blockspeicher, der über das Netzwerk verbunden ist. Für Produktionsdatenbanken in Kubernetes bietet Longhorn die Ausfallsicherheit, die der lokale Pfad nicht kann.

Auswahl der Speicherklasse nach Arbeitslast

• local-path: Zustandslose Pods, CI/CD-Build-Caches, temporäre Volumes für Batch-Jobs. Maximale Leistung, keine Replikation.
• Longhorn (1 Replik): Einzelknoten-Bereitstellungen , die PVC-Verwaltung ohne Knoten-Affinitätsbindung brauchen.
• Longhorn (2–3 Replikate): Produktionsdatenbanken , zustandsbehaftete Dienste, die auch bei Ausfällen von Knoten hochverfügbar sein müssen.

CNI-Plugin-Auswahl für Bare Metal

Cloud Kubernetes nutzt herstellerspezifische CNI-Plugins (VPC CNI für EKS usw.), die sich mit Cloud-Netzwerkprimitiven verbinden, die auf Bare-Metal-Systemen nicht verfügbar sind. Für Bare-Metal-K8s decken drei Plugins die meisten Anwendungsfälle ab:

• Flanell: Einfaches VXLAN-Overlay, am einfachsten zu bedienen, akzeptable Leistung für die meisten Workloads. Standard in k3s. Keine Durchsetzung von Netzwerkrichtlinien.
• Calico: BGP-basiertes Networking mit voller NetworkPolicy-Unterstützung. Das ist super für Produktionscluster, die eine Isolierung des Datenverkehrs zwischen Pods in verschiedenen Namespaces brauchen.
• Cilium: Basiert auf eBPF , hat den geringsten Overhead von den dreien und ersetzt iptables durch Paketverarbeitung auf Kernel-Ebene. Bietet die beste Leistung für Service-Meshes mit hohem Durchsatz. Ist aber etwas komplizierter in der Handhabung.

Für die meisten Teams, die mit Bare-Metal-K8s anfangen, bietet Calico genau das Richtige: volle Unterstützung von NetworkPolicy für die Sicherheitssegmentierung, stabilen Betrieb und eine gute Dokumentation. Cilium ist eine Überlegung wert, wenn der Cluster einen hohen Durchsatz im Ost-West-Verkehr hat, wo der Overhead von iptables in Calico spürbar wird.

LoadBalancer-Dienste ohne Cloud-Anbieter: MetalLB

Cloud Kubernetes richtet automatisch einen Cloud-Load-Balancer ein, wenn du einen Dienst vom Typ „LoadBalancer“ erstellst. Auf Bare-Metal-Systemen gibt's keinen Cloud-Anbieter, der diesen Load-Balancer einrichten könnte. Die Dienste bleiben dann auf unbestimmte Zeit im Status „Ausstehend“ hängen.

MetalLB löst dieses Problem. Es läuft als Controller im Cluster und teilt den LoadBalancer-Diensten IP-Adressen aus einem konfigurierten Pool zu. Im L2-Modus (einfacher) reagiert MetalLB auf ARP-Anfragen für Dienst-IPs von dem Knoten, auf dem sich der Dienstendpunkt befindet. Im BGP-Modus gibt es Routen direkt an Upstream-Router weiter, um eine ordnungsgemäße Lastverteilung zu gewährleisten.

Für die meisten InMotion-Dedizierten-Server-Bereitstellungen, die K8s laufen lassen, reicht MetalLB im L2-Modus mit einem kleinen IP-Pool (sogar ein /30-Subnetz mit zusätzlichen IPs) aus, um Dienste nach außen hin verfügbar zu machen. Füge einen Nginx zu MetalLB hinzu, um das HTTP/HTTPS-Routing zu verwalten, ohne eine dedizierte IP pro Dienst zu verbrauchen.

Bare Metal K8s vs. Managed Cloud K8s: Wann ist was besser?

Faktor	Bare Metal K8s	EKS / GKE / AKS
Kosten für Worker-Knoten pro Monat	99–350 $ (dediziert)	100–800+ Dollar (VM-Knoten)
Kosten für die Steuerungsebene	Selbstverwaltet (kostenlos)	72–150 $/Monat (Verwaltungsgebühr)
Speicherlatenz	NVMe (~0,1 ms)	Netzwerkblock (~1–5 ms)
Automatische Skalierung	Manuell oder Cluster-Autoscaler	Nativer Cloud-Autoscaler
Globale Regionen	Los Angeles, Amsterdam	Über 30 Regionen weltweit
Verwaltungsaufwand	Medium (kubeadm/k3s)	Niedrig (verwaltete Steuerungsebene)
Vorhersehbare monatliche Kosten	Ja	Variabel (nutzungsabhängig)

Bare Metal K8s ist super, wenn es um Kosten und Speicherleistung für stabile Workloads geht. Managed Cloud K8s ist top, wenn es um einfache Bedienung und globale Verteilung geht. Die richtige Wahl hängt davon ab, ob deine Workloads geografische Verteilungsanforderungen haben und ob dein Team eine Steuerungsebene verwalten kann.

Docker Swarm als einfachere Alternative

Nicht jede containerisierte Arbeitslast braucht Kubernetes. Docker Swarm auf einem einzigen dedizierten Server kann Dutzende von containerisierten Diensten mit einem Bruchteil der Komplexität von K8s verwalten. Wenn deine Architektur weniger als 10 bis 15 verschiedene Dienste hat und keine K8s-spezifischen Funktionen (benutzerdefinierte Ressourcendefinitionen, komplexe Planungsbeschränkungen, Helm-Ökosystem-Tools) braucht, lässt sich Swarm auf einem dedizierten InMotion-Server an einem Nachmittag einrichten.

Das Netzwerkmodell von Docker Swarm auf einem einzelnen Knoten ist einfacher als das von K8s: Overlay-Netzwerke für die Dienstermittlung, veröffentlichte Ports für den externen Zugriff, Traefik oder Nginx den Ingress. Keine CNI-Plugins. Kein MetalLB. Für Teams, die der Meinung sind, dass der Betriebsaufwand von K8s die architektonischen Vorteile ihrer Arbeitslast übersteigt, ist Swarm eine gute Wahl für die Produktion.

Erste Schritte

• Bestell einen Bare-Metal- oder dedizierten Server, Extreme-Tier für Produktions-K8s-Worker-Knoten.
• Installier k3s für Cluster mit einem Knoten oder leichte Cluster mit mehreren Knoten; kubeadm für die volle Kontrolle über die Cluster-Konfiguration.
• Richte Calico CNI von Anfang an für die Unterstützung von NetworkPolicy ein.
• Installiere MetalLB im L2-Modus, um den LoadBalancer-Dienst zu unterstützen.
• Richte den Local-Path-Provisioner für Entwicklungs-PVCs ein; Longhorn für produktionsreife Workloads mit Statusverwaltung.
• Füge Premier Care für die Verwaltung des Bare-Metal-Hosts auf Betriebssystemebene hinzu.

Teams, die jetzt 800 Dollar oder mehr pro Monat für verwaltete Kubernetes-Worker-Knoten zahlen, holen diese Kosten normalerweise schon im ersten Abrechnungszyklus nach der Migration von Workloads im Steady State auf Bare Metal wieder rein. Die Investition in die Verwaltung einer Steuerungsebene ist echt, aber es geht um einmalige Konfigurationskosten und nicht um laufende Kosten, die proportional zu deinen Rechenausgaben sind.