Das CNCF-Inkubationsprojekt und Istio Ambient Mesh Eine weniger invasive Alternative zum traditionellen Sidecar-Ansatz

Ein Gastbeitrag von Brian Gracely* |

Anbieter zum Thema

Vor Kurzem hat die Cloud Native Computing Foundation (CNCF) angekündigt, „Istio“ als Inkubationsprojekt zu akzeptieren. Das bedeutet, dass das beliebte Open-Source-Service-Mesh nun unter dem gleichen Dach weiterentwickelt wird, wie andere Cloud-native Projekte wie beispielsweise Kubernetes.

Mithilfe von „Istio Ambient Mesh“ bietet sich CNCF-Microservices auch ohne Sidecar eine Piste.
Mithilfe von „Istio Ambient Mesh“ bietet sich CNCF-Microservices auch ohne Sidecar eine Piste.
(Bild: gemeinfrei: Herbert Aust / Pixabay)

Service Meshes bilden einen wichtigen Bestandteil der Infrastruktur für Unternehmen auf dem Weg hin zu Cloud-nativen Umgebungen. Laut einer aktuellen Erhebung – „2022 Service Mesh Adoption Survey“ – modernisieren 85 Prozent der Unternehmen ihre Anwendungen hin zu einer Microservices-Architektur, während 87 Prozent der befragten Unternehmen ein Service Mesh verwenden oder evaluieren – im Zuge ihrer Bestrebungen, in einem großen Umfang bereitgestellte Container-basierte Architektur effektiver verwalten zu können.

„Service Mesh Adoption Survey“: Die Umfrage untersucht, wie Unternehmen Microservices einführen und wie sie „Kubernetes“ und „Istio“ nutzen.
„Service Mesh Adoption Survey“: Die Umfrage untersucht, wie Unternehmen Microservices einführen und wie sie „Kubernetes“ und „Istio“ nutzen.
(Bild: Solo.io)

Bei Hunderten oder mehr Microservices, die allesamt in einer variablen Anzahl von Containern ausgeführt werden, müssen Unternehmen nachverfolgen können, was in ihren Netzwerken passiert - damit die Konnektivität zwischen diesen Services sichergestellt werden kann. Es gibt zwar mehrere Service-Mesh-Projekte, aber Istio gilt als Industriestandard. Dieser bietet eine transparente, einheitliche und effiziente Methode zur Sicherung, Verbindung und Überwachung von Diensten in Cloud-nativen Anwendungen.

Google stellt „Istio“ der CNCF zur Verfügung und stellt so sicher, dass eine der am weitesten verbreiteten Service Mesh-Lösungen durch zusätzliche Plugins verstärkt werden kann. Ein Beispiel ist die „Istio Ambient Mesh“ Framework-Ankündigung von Google und Solo.io von Anfang September. Dieser Beitrag zu Istio stellt den Höhepunkt von fast einem Jahr Entwicklungsarbeit dar, die bei Solo.io begonnen hat und mit Google Engineering zusammengeführt wurde.

Ohne Sidecar-Ansatz unterwegs

Bevor die Funktionalität von Istio Ambient Mesh näher betrachtet wird, bietet es sich an, die Grundlagen des Sidecar-gesteuerten Ansatzes von Istio zu erläutern. Sidecars sind programmierbare Proxys, die neben Anwendungscontainern eingesetzt werden. Damit können Unternehmen die Vorteile von Istio nutzen, ohne bestehende Anwendungen umgestalten zu müssen.

Das bedeutet jedoch nicht, dass Sidecars perfekt sind. Sie sind invasiv, da sie in Anwendungen eingeschleust werden müssen, indem ihre Kubernetes-Pod-Spezifikationen geändert werden und der Datenverkehr innerhalb des Pods umgeleitet wird. Dies erfordert einen Neustart des Pods, wodurch die aktuell laufende Aufgabe unterbrochen wird.

Darüber hinaus müssen bei Sidecars die CPU- und Speicherressourcen für die schlimmstmögliche Nutzung jedes einzelnen Pods bereitgehalten werden. Angesichts der schieren Menge dieser Systeme in großen Unternehmen kann sich dies schnell zu erheblichen Reservierungen summieren, was zu einer Unterauslastung der Ressourcen im gesamten Cluster führt.

Das andere Istio-Netz

Grundsätzlich bietet Istio Ambient Mesh – mit seiner Sidecar-losen Option – eine Alternative zum Sidecar-zentrierten Ansatz von Istio. Es handelt sich um eine weniger invasive und einfachere Option, die sich für viele Nutzer von Service Mesh-Lösungen besser eignet. Außerdem wird damit neuen Nutzern der Einstieg in die Technologie erleichtert, da weniger Ressourcen für den Betrieb benötigt werden.

Installiert ein Plattformbesitzer Ambient in einem Cluster, laufen die vorhandenen Anwendungen einfach weiter. Der Eigentümer teilt dem System dann mit, dass eine bestimmte Anwendung Teil des Netzes sein muss, und das war's. Ein Neustart wird nicht nötig und es kommt zu keiner Unterbrechung.

Integrität der Sicherheit aufrechterhalten

Auch die Sicherheit wird nicht geschwächt. Istio hat Zero Trust Security implementiert und standardmäßig aktiviert. Dies erfolgt unabhängig davon, ob sich ein Unternehmen für eine Sidecar- oder eine Sidecar-freie Architektur entscheidet.

Die Sicherheit bleibt in die Umgebung integriert, so dass sich Technologieführer keinerlei Gedanken darüber machen müssen, ob sie diese gegen eine sonstige Funktionalität eintauschen müssen. Istio Ambient Mesh ist also ein Mittel zur Vereinfachung der Abläufe; es trägt dazu bei, die Infrastrukturkosten zu senken und verbreitert die Anwendungskompatibilität ohne negative Auswirkungen auf bestehende Abläufe.

Bei Istio Ambient Mesh handelt es sich um eine mehrschichtige Mesh-Datenebene mit einem sicheren Overlay. Dieses Overlay ist für die Transportsicherheit und das Routing zuständig. Es besteht auch die Möglichkeit, Layer 7-Funktionalität für die Namensräume einzuführen, die sie benötigen.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu RZ- und Server-Technik

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Das sichere Overlay besteht aus einer gemeinsam genutzten Komponente – dem Zero Trust Tunnel („ztunnel“). Dieses ist für die Layer 4-Telemetrie und mTLS (mutual transport layer security) zuständig. Darüber hinaus verbindet ztunnel die Elemente innerhalb des Netzes sicher und authentifiziert diese.

Die Trennung von Anwendungs- und Datenebene

Eine der Bedenken, die viele Unternehmen in Bezug auf ein Service Mesh äußern, lautet, dass ein Service Mesh die Komplexität im Betrieb erhöhen kann. Angesichts der Menge an Kubernetes-Implementierungen, auf die sich Unternehmen verlassen, ist dieses Hindernis für die Akzeptanz nur allzu verständlich. Bekannt ist ja, dass Komplexität zu Schwachstellen führt.

Von der Verarbeitung komplexer Geschäftslogik bis zur Nutzung von OSS-Bibliotheken oder fehlerhaften internen Shared Libraries ist der Anwendungscode eines Benutzers ein bevorzugtes Ziel für Angreifer. Wird eine Anwendung kompromittiert, sind Anmeldeinformationen, geheime Daten und Schlüssel für Angreifer zugänglich, einschließlich derjenigen, die in den Speicher eingebunden oder dort gespeichert sind. Beim Sidecar-Modell umfasst eine Anwendungskompromittierung die Übernahme des Sidecar und aller damit verbundenen Identitäts- und Schlüsselmaterialien.

Getrennt: Anwendung und Datenebene

Istio Ambient Mesh trennt die Anwendung von der Datenebene. Dies bedeutet, dass keine Komponenten der Datenebene im selben Pod wie die Anwendung laufen. Daher führt eine Kompromittierung der Anwendung nicht zum Zugriff auf geheime Daten.

Dies vereinfacht auch die Abläufe und verbessert die Sicherheit. Gleichzeitig werden Mehrfach-Mandanten-L7-Proxys vermieden. Dabei wird dafür gesorgt, dass das Sidecar-Modell weiterhin erstklassig unterstützt wird.

Dies geschieht durch ztunnel, welches die Belange der Datenebene von Istio vollständig von denen der Anwendung trennt. So können Betreiber die Datenebene aktivieren, deaktivieren, skalieren und aktualisieren, ohne die Anwendungen stören zu müssen.

Da ztunnel keine L7-Verarbeitung des Workload-Traffics durchführt, stellt sich das Ambient Mesh deutlich schlanker als ein Sidecar dar. Diese erhebliche Verringerung der Komplexität und der damit verbundenen Ressourcenkosten machen es möglich, dass es als gemeinsame Infrastruktur bereitgestellt werden kann.

So klappt es

Aufgrund ihres invasiven Charakters kann der Betrieb von Sidecars ein komplexes Unterfangen darstellen. Upgrades auf Workloads mit Sidecars erfordern mehr Planung und rollierende Neustarts, die möglicherweise koordiniert werden müssen, um die Anwendung nicht zum Absturz zu bringen. Ambient Mesh dient dazu, so etwas zu vermeiden. Ein Upgrade von ztunnel kann mit normalem ‚Node Patching‘ oder Upgrades zusammenfallen. Gleichzeitig sind die Waypoints-Proxys Teil des Netzes und können bei Bedarf vollständig transparent für die Anwendungen aufgerüstet werden.

Das Einbinden von Anwendungen in ein Service Mesh mithilfe von Ambient Mesh stellt sich so benutzerfreundlich wie die Kennzeichnung eines Namensraums dar. Daraus resultieren unmittelbare Vorteile für die Anwendungen, wie beispielsweise mTLS mit kryptografischer Identität für den Mesh Traffic und eine L4-Observability. Wer den Zugang oder die Routen kontrollieren, die Ausfallsicherheit erhöhen oder sich L7-Metriken für seine Anwendungen im Ambient Mesh sichern will, kann bei Bedarf Waypoints-Proxys auf seine Anwendungen anwenden.

Ambient Mesh und Sidecar

Natürlich ist das Istio Ambient Mesh nicht als Sidecar-Ersatz intendiert. Auch wenn das Istio Ambient Mesh für viele Mesh-Nutzer zukünftig die beste Option sein wird, sind Sidecars weiterhin eine ausgezeichnete Wahl. Dies gilt insbesondere für diejenigen, die dedizierte Datenebenen-Ressourcen benötigen, zum Beispiel für die Einhaltung von Vorschriften oder die Leistungsoptimierung.

Istio unterstützt auch weiterhin Sidecars – und ermöglicht es Sidecars, dass sie nahtlos mit dem Ambient Mesh interagieren können. Schließlich und endlich geht es darum, die beste Option für die spezifischen Anforderungen eines Unternehmens an das Service Mesh auszuwählen.

* Brian Gracely ist Head of Product Marketing bei Solo.io.

(ID:48840140)