Kubernetes ist ein guter Standard für die meisten Webplattformen.
Es bietet den Teams wiederholbare Bereitstellung, Ressourcenisolierung, Dienstentdeckung und ein ausgereiftes Betriebsmodell. Für die typische API, Arbeiterflotte oder interne Plattform überwiegen diese Vorteile die Overheadkosten.
Der Fehler besteht darin, dies in eine universelle Regel umzuwandeln.
Es gibt Workloads, bei denen Orchestrierungs-Overhead, virtualisierte Netzwerke und Verhaltensweisen von "lauten Nachbarn" keine Rundungsfehler sind. Sie sind die eigentliche Last.
Was die Plattform Hinzufügt
Kubernetes führt nicht nur Ihren Prozess aus. Es umgibt ihn mit einem breiteren Ausführungsmodell:
- Container-Netzwerk
- Dienst-Routing
- kube-proxy oder eBPF-basierte Paketverarbeitung
- cgroups und CPU-Planung
- Overlay-Netzwerke in vielen Umgebungen
Für die meisten Anwendungen ist dieser Overhead akzeptabel.
Für Systeme, die auf niedrige Tail-Latenz, Paketpacing oder direkte NIC-Interaktion Wert legen, ist das möglicherweise nicht der Fall.
Die Eigentliche Entscheidung Geht um Determinismus
Das Problem ist normalerweise nicht die durchschnittliche Latenz. Es ist die Varianz.
Einige Workloads kümmern sich viel mehr um Jitter als um Durchsatz:
- Paketverarbeitung
- Latency Trading
- Spezialisierte Telemetrieaufnahme
- Netzwerk im Benutzerspeicher mit DPDK oder ähnlichen Ansätzen
In diesen Systemen sind die Vorteile des Kubernetes Control Plane möglicherweise weniger wichtig als:
- feste CPU-Platzierung
- weniger Netzwerkschichten
- weniger Scheduler-Geräusch
- vorhersehbarerer Hardwarezugriff
Hier beginnen einfachere Bereitstellungsmodelle, dedizierte Hosts oder Bare Metal sinnvoll zu werden.
Die Meisten Teams Sollten Dies Nicht Als "Verlasse Kubernetes" Lesen
Für normale SaaS-Systeme ist die entgegengesetzte Schlussfolgerung normalerweise korrekt.
Wenn Ihr Produktengpass die Datenbanklatenz, unbegrenzte Wiederholungen, langsamen Objektspeicher oder teure Anwendung Logik ist, ist der Umstieg von Kubernetes wahrscheinlich nicht die Lösung.
Die Messlatte für den Wechsel von der Plattform sollte hoch sein.
Eine Bessere Methode zur Bewertung
Bevor Sie Kubernetes die Schuld geben, überprüfen Sie:
- Messen Sie die Tail-Latenz und nicht nur die Durchschnitte?
- Ist der Engpass Netzwerk, CPU-Planung oder etwas ganz anderes?
- Würde Node-Affinität, CPU-Pinning oder dedizierte Knoten genug des Problems lösen?
- Verwenden Sie ein CNI und Routing-Modell, das zum Workload passt?
Manchmal ist die richtige Antwort nicht "Bare Metal statt Kubernetes". Es ist "ein kleinerer, spezialisierter Cluster mit strikteren Platzierungsregeln."
Wann Bare Metal Vernünftig Wird
Bare Metal oder dedizierte Hosts werden defensibler, wenn:
- die Last extrem latenzsensitiv ist
- der Prozess direkten Hardwarezugriff benötigt
- Sie die operativen Kosten rechtfertigen können
- das Team ein maßgeschneiderteres Laufzeitmodell unterstützen kann
Das ist ein enger Bereich von Systemen. Es ist real, aber eng.
Kubernetes ist ein Orchestrierungssystem, keine Garantie für perfekten Hardware-Determinizmus. Wenn die Last Letzteres benötigt, seien Sie bereit, den einfacheren Stapel zu wählen.
Weitere Lektüre