Einleitung
Wenn über Serverless gesprochen wird, ist Kubernetes ein Thema, das nicht vermieden werden kann.
In der heutigen Lektion lernen wir weiter, wie man eine private Serverless-Umgebung einrichtet. Konkret bauen wir die Serverless-Infrastruktur auf Basis des lokalen K8s-Deployments aus der letzten Lektion auf. Dann installieren wir zusätzliche Komponenten, um die Fähigkeiten des K8s-Clusters zu erweitern, sodass der lokale K8s-Cluster schließlich Serverless unterstützt.
Voraussetzungen für den Aufbau von Serverless
Bevor wir beginnen, klären wir eine Frage, die während des Grundlagenkurses zu Serverless Computing, insbesondere FaaS, aufkam. Einige Studenten fragten: „Welche Beziehung besteht zwischen Microservices, Service Mesh und Serverless?“
Diese Konzepte tauchen häufig in Diskussionen auf, aber lasst euch nicht unter Druck setzen. Auch ich war von diesen Konzepten verwirrt, als ich anfing, mich mit Serverless zu beschäftigen. Schauen wir uns zunächst noch einmal Microservices an. Wenn man Microservices verwendet, um BaaS zu erstellen, ist einem vielleicht aufgefallen, dass viele Konzepte in Microservices denen in Serverless recht ähnlich sind.
Einfach ausgedrückt ist Service Mesh eine Netzwerkkommunikationslösung für Microservices, die ohne Wissen der Microservices selbst arbeitet. Wir können die Netzwerkkommunikation in einer Serverless-Architektur auch an ein Service Mesh delegieren. Durch Service Mesh können Serverless-Komponenten eng mit dem K8s-Cluster zusammenarbeiten und letztendlich unsere bereitgestellten Anwendungen auf Serverless-Weise unterstützen. Schauen wir uns das folgende Architekturdiagramm an:
Aus dem Diagramm wird deutlich, dass die zugrundeliegende Infrastruktur von Serverless auf Service Mesh aufgebaut werden kann. Allerdings ist Service Mesh nur eine der Lösungen zur Implementierung der Serverless-Netzwerkkommunikation. Es gibt auch andere Optionen wie RSocket, gRPC und Dubbo. Ich habe mich für Service Mesh entschieden, weil diese Lösung auf K8s-Komponenten basieren kann und Visualisierungswerkzeuge bietet, die uns helfen, den Serverless-Betriebsmechanismus zu verstehen – zum Beispiel, wie eine Nullstartzeit erreicht und der Datenverkehr für schrittweise Releases gesteuert werden kann. Wenn ihr praktisch arbeiten möchtet, ist Service Mesh zweifellos die erste Wahl.
Serverless-Infrastruktur: Service Mesh
Manche Leute bezeichnen Kubernetes, Service Mesh und Serverless-Technologien als die „drei Säulen“ der Cloud‑Native-Anwendungsentwicklung. Mittlerweile versteht ihr hoffentlich den Grund dafür. Ich muss jedoch klarstellen, dass wir in den folgenden Lektionen viele neue Begriffe einführen werden. Ich habe euch einen groben Überblick über diese Begriffe gegeben, damit ihr einen allgemeinen Eindruck habt. Wenn ihr Zeit habt, solltet ihr tiefer in sie eintauchen.
Kommen wir nun zum Hauptthema zurück und betrachten die Prinzipien von Service Mesh genauer.
Als wir über Microservices sprachen, haben wir nur die theoretische Anleitung zur Zerlegung und Integration behandelt, ohne auf die konkrete Implementierung einzugehen. Wenn wir zur Implementierung wechseln, gibt es in der Branche tatsächlich viele Microservice-Frameworks, aber die meisten sind auf die SDKs bestimmter Sprachen beschränkt, insbesondere Java‑Microservice-Frameworks.
Das Microservice-Framework in SDK‑Form legt in der Regel einen starken Fokus auf die Implementierung der Netzwerkkommunikation zwischen Microservices, wie das Wiederholen fehlgeschlagener Serviceanfragen, Lastverteilung über mehrere Serviceinstanzen und Traffic-Begrenzung bei hohem Serviceanfragevolumen. Diese Logiken erfordern oft die Aufmerksamkeit der Microservice-Entwickler und müssen in jeder SDK‑Sprache wiederholt implementiert werden. Ist es also möglich, die Microservice-Netzwerkkommunikationslogik aus dem SDK zu extrahieren, um unsere Microservices leichter zu machen und uns sogar keine Gedanken mehr über die Netzwerkkommunikation machen zu müssen?
Die Antwort lautet Service Mesh.
Wenn wir zerlegte Anwendungen in Pods eines K8s-Clusters bereitstellen, läuft der Prozess wie im Diagramm unten ab, wo die MyApp‑Anwendung den User‑Microservice und den To‑Do‑Microservice innerhalb des Clusters direkt per HTTP aufruft.
Aber was ist mit den Sicherheitsproblemen, die durch direkten HTTP‑Zugriff entstehen? Wenn jemand einen BusyBox‑Container in unserem Cluster startet, könnte er dann nicht direkt unseren User‑Microservice und To‑Do‑Microservice angreifen? Und wenn wir mehrere Instanzen des User‑Microservice haben, wie verteilen wir den Datenverkehr?
Traditionell würden wir ein Microservice‑Architektur‑SDK verwenden, das viel dieser Logik und viele Strategien enthält, bei denen wir entscheiden müssen, wann sie beim Aufruf des SDK aktiviert werden. Unser Code wäre auch stark an das Microservice‑Architektur‑SDK gekoppelt.
Service Mesh geht jedoch einen anderen Weg, indem es die Netzwerkkommunikationslogik aus dem Microservice extrahiert und den Netzwerkverkehr auf nicht‑invasive Weise verwaltet, sodass wir uns nicht mehr um das schwere Microservice‑SDK kümmern müssen. Sehen wir uns an, wie Service Mesh dieses Problem löst.
Service Mesh kann in eine Datenebene und eine Steuerungsebene unterteilt werden. Die Datenebene ist für die Verwaltung der Netzwerkkommunikation zuständig, während die Steuerungsebene den Status der Netzwerkkommunikation steuert und überwacht. Service Mesh fängt den gesamten Netzwerkverkehr ab, indem ein Sidecar injiziert wird.
In der Datenebene scheinen unsere Anwendungen und Microservices direkt mit dem Sidecar zu kommunizieren, aber tatsächlich kann der Sidecar dies durch Traffic‑Hijacking erreichen. Daher sind sich unsere Anwendungen und Microservices dessen im Allgemeinen nicht bewusst und benötigen keine Änderungen – sie verwenden einfach HTTP‑Anfragen zur Datenübertragung.
Die Steuerungsebene ist komplexer und das Herzstück des Service‑Mesh‑Betriebs. Der Pilot ist der Treiber der gesamten Steuerungsebene und verantwortlich für Service‑Discovery, Datenverkehrsmanagement und Skalierung. Citadel ist die Schutzfestung der Steuerungsebene, zuständig für Sicherheitszertifikate und Authentifizierung. Mixer ist der Kommunikationsbeauftragte, der die Richtlinien der Steuerungsebene verteilt und den Betriebsstatus jedes Dienstes sammelt.
Jetzt solltet ihr ein klares Verständnis davon haben, was Service Mesh ist, wie es die Microservice‑Netzwerkkommunikationslogik aus dem SDK extrahiert und warum wir sagen, dass Service Mesh die Netzwerkkommunikationsgrundlage für Serverless ist.
Die Beziehung zwischen Serverless und Container‑Engines
Der Kernwert von Serverless liegt darin, keine Server verwalten zu müssen und sich auf die Geschäftslogik konzentrieren zu können. Die Containertechnologie bietet die leistungsstarke Infrastruktur und die flexiblen Planungsfähigkeiten, die für Serverless erforderlich sind, insbesondere in Kombination mit Orchestrierungswerkzeugen wie Kubernetes.
Container bieten Vorteile wie leichtes Packaging, Ressourcenisolierung und schnelle Startzeiten. Container verpacken Anwendungen und ihre Abhängigkeiten, gewährleisten Konsistenz der Laufzeitumgebung und erleichtern die schnelle Bereitstellung und den Start von Anwendungsinstanzen auf einer Serverless‑Plattform. Darüber hinaus bieten Container isolierte Laufzeitumgebungen, sodass sich verschiedene Anwendungen nicht gegenseitig beeinträchtigen, was die Gesamtstabilität der Plattform verbessert. Außerdem ist der Start von Containern schneller als der von virtuellen Maschinen, was die hohen Anforderungen von Serverless‑Anwendungen an elastische Skalierung erfüllt.
Als Kern der Serverless‑Planung bietet Kubernetes Funktionen wie automatisierte Bereitstellung, elastische Skalierung und Service‑Discovery. Es kann containerisierte Anwendungen basierend auf voreingestellten Regeln automatisch bereitstellen, ohne manuelles Eingreifen. Es passt die Anzahl der Anwendungsinstanzen je nach aktueller Last an, optimiert die Ressourcennutzung bei gleichzeitiger Leistungssicherung und bietet Service‑Discovery‑Mechanismen, die die Kommunikation zwischen Komponenten innerhalb der Serverless‑Plattform erleichtern.
Um eine containerbasierte Serverless‑Plattform aufzubauen, müsst ihr zunächst Anwendungen und ihre Abhängigkeiten in Container‑Images verpacken, um sicherzustellen, dass die Anwendungen schnell auf der Plattform bereitgestellt und ausgeführt werden können. Wählt dann eine geeignete Cloud‑Plattform oder richtet einen selbst gehosteten Kubernetes‑Cluster als Infrastruktur für die Serverless‑Plattform ein. Entwickelt als Nächstes Serverless‑Plattformkomponenten, darunter ein API‑Gateway zum Empfangen und Weiterleiten externer Anfragen, eine Funktion‑Laufzeit zum Laden und Ausführen von Funktionscode und zum Verwalten des Funktionslebenszyklus sowie Ereignis‑Trigger, die auf verschiedene Ereignisquellen hören und Ereignisse in Funktionsaufrufe umwandeln. Verwendet schließlich Kubernetes’ Deployment zur Verwaltung der Bereitstellung und Aktualisierung von Anwendungsinstanzen, Service für Service‑Discovery und Lastverteilung sowie HPA für automatische elastische Skalierung.
Eine containerbasierte Serverless‑Plattform bietet hohe Flexibilität, starke Anpassbarkeit und Kosteneffizienz. Entwickler können die zugrundeliegende Containertechnologie und die Kubernetes‑Plattform frei wählen, die Funktionen und Merkmale der Serverless‑Plattform nach Bedarf anpassen und die Ressourcenplanungsfähigkeiten von Kubernetes nutzen, um die Ressourcennutzung zu optimieren und Kosten zu senken.
Die Kombination von Containertechnologie und Kubernetes bietet leistungsstarke Werkzeuge und Methoden für den Aufbau effizienter, flexibler und skalierbarer Serverless‑Plattformen und ermöglicht Entwicklern, ihre eigenen Serverless‑Plattformen einfach aufzubauen, sich auf die Entwicklung der Geschäftslogik zu konzentrieren und die Entwicklungsproduktivität zu steigern.
Novita AI Serverless
Bei Novita AI haben wir unsere eigene Container‑Engine, Nexus, entwickelt. Mit den leistungsstarken verteilten Rechen‑ und Ressourcenplanungsfähigkeiten von Nexus hat Novita AI einen Serverless‑Service aufgebaut, der auf die nächste Generation generativer KI ausgerichtet ist. Benutzer müssen sich nur auf geschäftliche Innovationen konzentrieren, ohne sich um die zugrundeliegenden Rechenressourcen kümmern zu müssen. Reservierungen sind jetzt möglich; tretet der Warteliste bei, um Novita AI Serverless als Erste zu erleben.
Novita AI ist die All‑in‑one‑Cloud‑Plattform, die eure KI‑Ambitionen unterstützt. Integrierte APIs, Serverless, GPU‑Instanz – die kosteneffektiven Werkzeuge, die ihr braucht. Infrastruktur überflüssig machen, kostenlos starten und eure KI‑Vision verwirklichen.
Empfohlene Lektüre
Skalierung nach Bedarf: Wie Serverless mühelos mit Traffic‑Spitzen umgeht
Die Revolution enthüllen: Die Welt des Serverless Computing erkunden
