Getty Images/iStockphoto
WebAssembly und Kubernetes: Verstehen Sie die Beziehung
WebAssembly bietet eine Möglichkeit zur Erstellung von portablen Webanwendungen. Die Kopplung von Wasm mit Kubernetes erleichtert die Orchestrierung und Verwaltung des Prozesses.
Wenn heute jemand online Bankgeschäfte, Einkäufe oder Nachrichten tätigt, ist es wahrscheinlich, dass eine Webanwendung die Arbeit erledigt. Angesichts der steigenden Nachfrage nach Webanwendungen ist WebAssembly in Kombination mit Kubernetes eine vielversprechende Lösung für die Erstellung vielseitiger und verwaltbarer Webanwendungen.
Webanwendungen profitieren heute von der plattformübergreifenden Benutzerfreundlichkeit. Sie können auf einer Vielzahl von Betriebssystemen und Geräten ausgeführt werden – alles, was zählt, ist der Browser. Das vereinfacht die Entwicklungs- und Bereitstellungszyklen, da nichts außerhalb des lokalen Browsers installiert oder konfiguriert werden muss.
Viele Webanwendungen werden in Sprachen wie JavaScript erstellt und in virtuellen Containern wie Docker-Containern bereitgestellt und über Orchestrierungsplattformen wie Kubernetes verwaltet. Heutzutage werden Container und Orchestrierung in der Public Cloud gehostet, was zu einem hohen Grad an Automatisierung und Skalierbarkeit führt, der für moderne Geschäftsabläufe unerlässlich ist.
Eine neue Anwendungsplattform namens WebAssembly (Wasm) stellt die langfristige Beziehung zwischen Docker-Containern und Kubernetes-Orchestrierung in Frage. Wasm ermöglicht es sowohl browserbasierten als auch serverseitigen Anwendungen, komplexere Funktionen (beispielsweise Echtzeit-Rendering und Grafiken) auszuführen, die lange Zeit jenseits der Möglichkeiten herkömmlicher Webcodierungssprachen wie JavaScript lagen. Die Wasm-Kompilierung liefert Binärcode, der häufig besser komprimiert wird und eine bessere Anwendungsleistung bietet als herkömmliche webbasierte Sprachen.
Grundlagen von WebAssembly
Wasm ist ein Art Low-Level-Assembler-Sprache, mit der verschiedene gängige Programmiersprachen kompiliert werden können. So kann beispielsweise ein in C, C++ oder Rust geschriebenes Programm in ein Wasm-Binärmodul kompiliert werden. Wasm ist für die Koexistenz mit traditionellen Webanwendungssprachen wie JavaScript gedacht, und beide arbeiten im Browser zusammen.
Wie bei jeder Assemblersprache ist der resultierende Maschinencode nahe an der nativen Computerhardware. Das führt zu einer schnellen und effizienten Programmleistung, die es Wasm-Anwendungen ermöglicht, komplexer zu sein und mehr Systemressourcen zu beanspruchen als JavaScript-Anwendungen. Das gibt Entwicklern die Möglichkeit, kreativere und anspruchsvollere Webanwendungen zu entwickeln als mit JavaScript allein.
Wasm-Programme laufen in unterstützten Browsern, das heißt, den meisten gängigen Webbrowsern, und können über eine modulare Schnittstelle namens WebAssembly System Interface (oder WASI), die sich durch ihre Sicherheit und Portabilität über verschiedene Betriebssysteme hinweg auszeichnet, in anderen Laufzeiten ausgeführt werden. Es gibt noch weitere WASI-Laufzeiten wie Wasmtime und WasmEdge.
Wasm und Docker im Vergleich
Auf einer hohen Ebene haben Wasm und Docker ein ähnliches Vorhaben. Beide zielen darauf ab, ein portables Modul bereitzustellen, das in jeder hardwarekompatiblen Umgebung geladen und ausgeführt werden kann. Docker erreicht das, indem es einen Snapshot von Systemdateien und Abhängigkeiten erstellt und diese Elemente in Schichten anordnet, die dann innerhalb einer Container-Engine/Laufzeitumgebung wie Docker geladen und ausgeführt werden können.
Die Herausforderung für Docker und seine Container ist die Kompatibilität. Eine Docker-Image-Datei mit all ihren Komponenten und Abhängigkeiten muss mit dem zugrunde liegenden System oder der Hardware-Architektur übereinstimmen, für die sie bestimmt ist (wie Intel, AMD oder ARM). Andernfalls wird der Container nicht korrekt ausgeführt, wenn er überhaupt läuft.
Wasm wählt einen einfacheren Ansatz als Docker. Ein Programm in C, C++, Rust, Go oder einer anderen Sprache wird zu einer ausführbaren Binärdatei kompiliert, die auf einer geeigneten Wasm-Laufzeitumgebung ausgeführt werden kann. Browser enthalten eine geeignete native Laufzeitumgebung und benötigen keine weitere externe Laufzeitumgebung. Es gibt jedoch Dutzende von potenziellen Wasm-Laufzeiten, die zum Laden und Ausführen von Wasm-Modulen für Nicht-Browser-Anwendungen verwendet werden können, zum Beispiel für serverseitige oder Backend-Workloads.
Der Schlüssel dazu ist, dass Wasm-Binärdateien nicht auf Host-Betriebssysteme oder Prozessorarchitekturen wie Docker-Container angewiesen sind. Stattdessen werden alle Ressourcen, die das Wasm-Modul benötigt (zum Beispiel Umgebungsvariablen und Systemressourcen), dem Wasm-Modul von der Laufzeitumgebung über den WASI-Standard zur Verfügung gestellt. Das bedeutet, dass Wasm-Module nicht an das Betriebssystem oder den zugrunde liegenden Computer gekoppelt sind. Das ist ein idealer Mechanismus für die hochgradig portable Entwicklung webbasierter Anwendungen.
Kubernetes, Wasm und Docker im Vergleich
Mit dem Aufkommen der Containertechnologie unter Verwendung von Plattformen wie Docker entstanden Verwaltungsprobleme für Entwickler und Betriebspersonal. Container sind klein, verbreiten sich schnell und existieren nur für sehr kurze Zeiträume, was die manuelle Bereitstellung und Verwaltung komplexer, aus Containern zusammengesetzter Anwendungen erschwert.
Kubernetes entstand als Antwort auf diese Herausforderungen und bietet eine vielseitige und leistungsstarke Plattform zur Automatisierung, Orchestrierung und Verwaltung containerbasierter Umgebungen. Kubernetes hat eine hohe Akzeptanz in der Branche erlangt und ist zum Standard für die Container-Verwaltung in Unternehmen geworden. Zu seinen Funktionen gehören automatische Skalierung, Lebenszyklusmanagement, deklaratives Systemzustandsmanagement, Ausfallsicherheit, Selbstheilung, persistente Speicherung von Containern und Lastausgleich.
Docker-Container auf Kubernetes
Kubernetes und Docker sind nicht direkt miteinander verbunden. Tatsächlich hat Docker seine eigene Orchestrierungsplattform namens Docker Swarm – aber die Popularität von Kubernetes macht es zu einer gängigen Lösung für die Kombination mit Docker. Während Docker die Engine für den Betrieb von Containern ist, ist Kubernetes die Plattform, die Unternehmen dabei hilft, unzählige Container zu verwalten, während sie bereitgestellt werden, sich vermehren und dann wieder verschwinden.
Eine typische Containerbereitstellung in Kubernetes verwendet containerd als Hauptverwaltungslaufzeit, um Containeraufgaben wie das Erstellen, Starten, Stoppen und Entfernen von Containern zu verwalten. Runc ist jedoch die eigentliche Low-Level-Container-Laufzeit, die die von containerd verwalteten Ereignisse ausführt. Normalerweise wird ein zusätzlicher Shim-Prozess hinzugefügt, um die Schnittstelle zwischen der Low-Level-Laufzeit und containerd zu bilden.
Wasm-Module in Kubernetes
Wasm hat die gleichen Verwaltungsprobleme wie herkömmliche Container. Es ist einfach, ein oder zwei Wasm-Module in einen Browser zu laden, aber die Verwaltung von Hunderten oder sogar Tausenden von Backend-Wasm-Modulen auf Unternehmensservern kann ein ganz anderes Problem darstellen. Daher ist bei einer größeren Anzahl von Modulen eine umfassendere Form der Orchestrierung und Verwaltung erforderlich. Obwohl Wasm über keine native Orchestrierungsplattform verfügt, kann Kubernetes diese Rolle in einer Wasm-Umgebung übernehmen.
Um Wasm-Module für Container zu betreiben, muss die Low-Level-Laufzeit zusammen mit dem Shim ersetzt werden, der die Schnittstelle zwischen der Low-Level-Laufzeit und der containerd-Management-Laufzeit in Kubernetes bildet.
Einer der gebräuchlichsten Shim-Ersatzprogramme ist runwasi, das zwischen containerd und Low-Level-Wasm-Laufzeiten installiert werden kann. Es gibt auch zahlreiche Low-Level-Wasm-Laufzeiten, darunter wasmtime, WasmEdge und runtime-X.
An dieser Stelle können Wasm-Module anstelle von Containern geladen werden. Dieses Ersetzungssystem funktioniert, weil die Shims, die Low-Level-Laufzeiten und die tatsächlichen Arbeitslasten für Kubernetes völlig irrelevant sind. Kubernetes plant die Aufgaben und unterscheidet nicht zwischen OCI-konformen Containern und Wasm-Arbeitslasten.
Der eigentliche Code, der zur Durchführung dieser Ersetzungen und zur Konfiguration von Kubernetes für die Ausführung von Wasm-Arbeitslasten erforderlich ist, findet sich routinemäßig in WebAssembly und in der Dokumentation für Wasm-Laufzeiten.
Kompromisse von Wasm auf Kubernetes
Obwohl die Verwendung von Kubernetes als Orchestrierungsplattform für Wasm-Anwendungen die Akzeptanz und das Wachstum von Wasm fördert, ist Wasm nicht dazu gedacht, Docker-Container zu ersetzen. Kubernetes kann problemlos sowohl Container als auch Wasm-Workloads gleichzeitig unterstützen, was eine große Vielseitigkeit bei der Gestaltung und Bereitstellung zukünftiger Anwendungen ermöglicht.
Wasm und seine Präsenz in Kubernetes bilden folgende Vorteile:
- leichter, kompakter und hochgradig portabler Code
- hohe Leistung für komplexe Anwendungen
- einfache Integration von Wasm-Modulen in Kubernetes
- reichhaltiges Ökosystem von Wasm-Laufzeiten
- keine Änderungen an Kubernetes, das weiterhin gleichzeitig traditionelle Container unterstützen kann
Die Ausführung von Wasm auf Kubernetes kann jedoch einige potenzielle Nachteile mit sich bringen:
- Es gibt zusätzliche Lernkurve und mehr konzeptionelle Belastung für Entwickler und Betriebsmitarbeiter.
- Die große Anzahl von Wasm-Laufzeiten kann in Bezug auf Zweck, Qualität und Herstellerunterstützung variieren.
- Mehr Tools, die zum Kompilieren und Testen von Wasm-Modulen benötigt werden, können CI/CD-Toolchains weiter verkomplizieren.
- Die allgemeine Stabilität von Wasm in Kubernetes ist nicht garantiert.
Die Ausführung von Wasm-Workloads in Kubernetes ist derzeit eine experimentelle Initiative. Die Stabilität und Leistung der sich daraus ergebenden Betriebskonfigurationen sind zum jetzigen Zeitpunkt nicht unbedingt für größere Produktionseinsätze geeignet. Die Möglichkeit, Wasm-Workloads zusammen mit Docker-Containern über Kubernetes auszuführen, bietet Entwicklern jedoch überzeugende Möglichkeiten für Innovationen. Experimentier- und Proof-of-Concept-Projekte können aus dieser neuen und sich verändernden Entwicklungsbemühungen Nutzen ziehen.
