- Runtime-Tool, entwickelt, um in Kubernetes-Umgebungen die Ressourcenverschwendung durch inaktive Container zu verringern
- Wenn für eine bestimmte Zeit keine TCP-Verbindung besteht, wird der Container automatisch als Checkpoint auf die Festplatte gespeichert
- Arbeitet in Form eines containerd shim, speichert den Speicherzustand des Containers, beendet ihn und stellt ihn bei der ersten späteren Verbindung innerhalb weniger Millisekunden wieder her
- Bei der Wiederherstellung wird der gesamte Zustand der Anwendung unverändert rekonstruiert, sodass aus Sicht der Nutzer fast keine Verzögerung entsteht
- Verwendet eBPF-basiertes Redirecting, um TCP-Pakete an einen Proxy weiterzuleiten, und schaltet nach abgeschlossener Wiederherstellung auf eine direkte Verbindung um
- Führt Checkpointing und Wiederherstellung mit CRIU - Checkpoint and Restore in Userspace durch
- Bietet über die Aktivierungssequenz (activation sequence) einen Ablauf, bei dem die automatische Wiederherstellung bei der ersten Anfrage erfolgt
- Enthält eine intelligente Wartelogik, die jüngste TCP-Aktivität verfolgt, um häufiges Anhalten und Wiederherstellen zu vermeiden
- Unter Kubernetes wird der Container weiterhin als laufend erkannt, wodurch ein Neustart der Runtime verhindert wird
- Bei Ausführung des Befehls
kubectl exec erfolgt eine automatische Wiederherstellung, sodass der Zugriff wie bei einem normalen Container möglich ist
- Jeder Shim-Prozess sammelt Metriken, und ein zeropod-manager auf Node-Ebene führt sie zusammen und stellt sie über einen HTTP-Endpunkt bereit
- Bietet in-place scaling, das Ressourcenanforderungen dynamisch anpasst, falls der Cluster dies unterstützt
- Beim Draining eines Nodes können herunterskalierte Pods auf andere Nodes migriert werden
- Unterstützt experimentell auch Live-Migration
- Geeignet für Services mit wenig Traffic, Entwicklungs- und Staging-Umgebungen, günstige Tiers von Heroku-ähnlichen Plattformen sowie Backend-Konfigurationen statischer Websites
- Die meisten Programme funktionieren ohne gesonderte Anpassungen, und CRIU-Fehler lassen sich über die containerd-Logs analysieren
4 Kommentare
Eine Neuerfindung von
inetd? (Scherz)Der Elastic Machine Pool von Platform 9, den ich letztes Jahr auf der AWS re:Invent gesehen habe, wirkte damals etwas abschreckend, weil er nur für B2B gedacht war, wenn man ihn nur mal kurz ausprobieren wollte. Das hier ist aber einfach zu installieren und funktioniert auch sehr intuitiv, was mir gefällt. Ich wollte in der Entwicklungsumgebung Ressourcen aggressiv zuweisen, ohne die User Experience zu beeinträchtigen. Wenn ein PoC gut läuft, scheint es durchaus eine Überlegung wert zu sein, das einzuführen.
Ich fragte mich, was der Unterschied zu KNative ist, und offenbar sind die folgenden zwei Sätze der Kern.
containerd-Shims, speichert den Speicherzustand des Containers, beendet ihn und stellt ihn später bei der ersten Verbindung innerhalb weniger Millisekunden wieder herlambda. . .. ?