Video verzeiht nichts: Warum „Bare Metal“ bei Live-Streaming an seine Grenzen stößt

Im Vergleich zu klassischen Web-Anwendungen ist Video eine völlig andere Spezies von Workload. Während ein Webserver eine kurze Lastspitze oft durch leicht verzögerte Antwortzeiten abfedern kann, ist Video absolut intolerant. Eine CPU-Spitze von wenigen Millisekunden führt bei einem Live-Stream nicht zu „Warten", sondern zu sichtbaren Artefakten, Audio-Aussetzern oder - im schlimmsten Fall - zum kompletten Abbruch der Verbindung.

Viele Unternehmen setzen für ihre Video-Plattformen historisch bedingt auf Bare-Metal-Server. Die Logik dahinter: „Ich brauche die volle Power der CPU ohne Virtualisierungs-Overhead." Doch was in der Theorie nach Performance klingt, wird in der Praxis bei wachsenden Nutzerzahlen zum operativen und wirtschaftlichen Albtraum.

Das Problem: Die Unberechenbarkeit der Last

Video-Workloads sind extrem volatil. Ein typischer Verlauf bei einem Live-Streaming-Anbieter sieht oft so aus:

• Montag bis Mittwoch: Grundrauschen durch kleinere Meetings und On-Demand-Abrufe. Die Server langweilen sich bei 5 % Auslastung.
• Donnerstag, 10:00 Uhr: Ein DAX-Konzern hält seine Quartals-Townhall mit 5.000 Zuschauern. Die CPU-Last schießt innerhalb von Sekunden auf 95 %.
• Donnerstag, 11:30 Uhr: Das Event endet. Die Last fällt schlagartig wieder auf das Grundrauschen zurück.

Die Bare-Metal-Falle

Wer auf dedizierte Server setzt, muss für den Worst Case dimensionieren. Das bedeutet: Sie bezahlen 24/7 für die Hardware-Power, die Sie benötigen, um den Peak am Donnerstagmorgen abzufangen. Den Rest der Woche verbrennen Sie bares Geld für ungenutzte Ressourcen.

Wächst Ihr Geschäft und ein zweiter Großkunde kommt hinzu, müssen Sie neue Server bestellen, installieren und konfigurieren. Dieser Prozess dauert Tage oder Wochen – viel zu langsam für das dynamische Event-Geschäft.

Die technische Sackgasse: Fehlende Resilienz

Ein weiteres Problem von Bare Metal im Video-Kontext ist die mangelnde Flexibilität bei Ausfällen. Wenn der RTMP-Ingest-Prozess (der den Videostream vom Produzenten empfängt) auf einem fest zugewiesenen Server läuft und diese Hardware einen Defekt erleidet, ist der Stream weg.

Ohne eine Orchestrierungsschicht wie Kubernetes gibt es:

• Kein Self-Healing: Der Prozess startet nicht automatisch auf einem anderen gesunden Knoten neu.
• Kein Failover: Die Zuschauer sehen ein Standbild, während die Administratoren hektisch versuchen, DNS-Einträge auf einen Ersatzserver umzubiegen.
• Keine Lastverteilung: Ein einzelner, sehr großer Stream kann nicht einfach auf mehrere Maschinen „aufgeteilt" werden, wenn die CPU des Bare-Metal-Servers am Limit ist.

Die Lösung: Cloud-Native Video-Infrastruktur

Um Video-Streaming profitabel und SLA-fähig zu betreiben, muss die Infrastruktur elastisch sein. Das Ziel ist ein System, das nicht aus starren Servern besteht, sondern aus einem Pool von Ressourcen, der mit der Last „atmet".

1. Horizontale Skalierung statt dicker Knoten

Anstatt einen riesigen Server für alle Meetings zu nutzen, verteilen wir die Last auf viele kleine Einheiten (Pods). Kommen mehr Zuschauer, fährt das System in Sekunden zusätzliche Instanzen hoch.

2. Node-Autoscaling

Wenn der gesamte Ressourcen-Pool im Cluster knapp wird, sorgt ein Node-Autoscaler dafür, dass automatisch neue virtuelle oder physische Maschinen zum Cluster hinzugefügt werden – und nach dem Event auch wieder verschwinden.

3. Containerisierte Video-Engines

Durch den Einsatz moderner Engines wie LiveKit in Containern wird Video zu einem Workload, der sich wie jede andere Applikation verhält: portabel, schnell startend und isoliert.

Fazit: Flexibilität gewinnt gegen rohe Gewalt

Bare Metal hat seine Berechtigung für statische, vorhersehbare Lasten. Doch Video-Streaming ist das genaue Gegenteil. Wer in diesem Markt bestehen will, darf seine Infrastruktur nicht „basteln", sondern muss sie als automatisierte Plattform begreifen. Nur wer elastisch skaliert, kann die hohen Qualitätsanforderungen der Kunden erfüllen, ohne an den Hardware-Fixkosten zu ersticken.

FAQ

Ist die Virtualisierung bei Kubernetes nicht zu langsam für Video? Nein. Moderne Container-Runtimes und Netzwerk-Plugins (wie Cilium) haben einen minimalen Overhead, der für 99,9 % der Video-Usecases absolut vernachlässigbar ist. Die Vorteile durch Orchestrierung überwiegen diesen minimalen Faktor bei weitem.

Was passiert bei einem Hardware-Ausfall in einem Kubernetes-Cluster? Kubernetes erkennt den Verlust eines Knotens sofort. Die Video-Pods werden auf den verbleibenden gesunden Knoten neu gestartet. In Kombination mit intelligenten Clients (die automatisch einen Reconnect versuchen) bemerken die Zuschauer oft nur ein minimales Ruckeln statt eines Totalausfalls.

Können wir unsere bestehenden Bare-Metal-Server in Kubernetes einbinden? Ja, das ist oft ein idealer Zwischenschritt. Man nutzt die vorhandene Hardware als statische Basis-Kapazität des Clusters und skaliert bei Lastspitzen flexibel in die Cloud (Hybrid Cloud) hinzu.

Wie reagiert Kubernetes auf die extremen CPU-Anforderungen von Video-Transcoding? Video-Transcoding ist ein “CPU-fressender” Job. In Kubernetes können wir diesen Jobs exakte Ressourcen-Limits und -Garantien zuweisen. So stellen wir sicher, dass ein rechenintensives Transcoding niemals die Echtzeit-Übertragung eines anderen Live-Events stört.