Die Einführung von VMware Tanzu Service Mesh

Glauben Sie mir, wenn ich sage, dass Tanzu Service Mesh (TSM) auf dem Weg ist der nächste Superstar im VMware-Portfolio zu werden. Hier würde mir Joe Baguley sicherlich zustimmen:

Wenn Sie jemanden über Tanzu Service Mesh schreiben hören oder sehen, kommen Sie sehr schnell zu dem Punkt, an dem die sogenannten “Global Namespaces” (GNS) erwähnt werden, die die magische Kraft haben, hybride Anwendungen zusammenzufügen, die in mehreren Clouds laufen.

Namespaces

Bevor wir über Tanzu Service Mesh und die magische Kraft von Global Namespaces sprechen, lassen Sie uns zunächst einen Blick auf den Begriff “Namespaces” werfen.

Kubernetes Namespace

Namespaces ermöglichen die Organisation von Clustern in virtuell ausgegliederte Sub-Cluster, was hilfreich sein kann, wenn verschiedene Teams, interne Kunden oder Projekte dieselben Kubernetes-Cluster nutzen. Diese Form eines Namespaces bietet eine Methode zur besseren gemeinsamen Nutzung von Ressourcen, da sie eine faire Zuweisung dieser Ressourcen mit den richtigen Berechtigungen gewährleistet.

Durch die Verwendung von Namespaces können Sie also sicherstellen, dass Entwickler andere Projektteams nicht beeinträchtigen. Richtlinien ermöglichen die Konfiguration von Rechenressourcen durch die Festlegung von Ressourcenquoten für die CPU- oder Speichernutzung. Dadurch wird auch die Leistung eines bestimmten Namespaces, seiner Ressourcen (Pods, Dienste usw.) und des Kubernetes-Clusters im Allgemeinen sichergestellt.

Obwohl Namespaces voneinander getrennt sind, können sie miteinander kommunizieren. Netzwerkrichtlinien können so konfiguriert werden, dass isolierte und nicht isolierte Pods entstehen. Eine Netzwerkrichtlinie kann zum Beispiel den gesamten Datenverkehr aus anderen Namespaces zulassen oder verbieten.

Ellei Mei hat dies in ihrem Artikel nach der Bekanntgabe von Project Pacific im September 2019 sehr einfach erklärt:

Stellen Sie sich einen Bauern vor, der sein Feld (Cluster + Cluster-Ressourcen) in eingezäunte kleinere Felder (Namespaces) für verschiedene Tierherden unterteilt. Die Kühe in einem eingezäunten Feld, die Pferde in einem anderen, die Schafe in einem anderen, usw. Der Landwirt wäre hier das Operations, das diese Namespaces definiert und die Tiere wären wie Entwicklerteams, die innerhalb der ihnen zugewiesenen Grenzen tun dürfen, was immer sie tun.

vSphere Namespace

Das erste Mal, dass ich von Kubernetes oder vSphere Namespaces gehört habe, war tatsächlich auf der VMworld 2019 in Barcelona. Damals stellte VMware ein neues App-fokussiertes Managementkonzept vor. Dieses Konzept beschrieb eine Möglichkeit, moderne Anwendungen und alle ihre Teile zu modellieren und wir nennen dies heute einen vSphere Namespace.

Mit Project Pacific (heute bekannt als vSphere with Tanzu oder Tanzu Kubernetes Grid) ging VMware einen Schritt weiter und erweiterte den Kubernetes Namespace um weitere Optionen für die Zuweisung von Rechenressourcen, vMotion, Verschlüsselung, Hochverfügbarkeit, Backup & Restore und Snapshots.

Anstatt sich mit jedem Namespace und seinen Containern auseinandersetzen zu müssen, können vSphere Namespaces (manchmal auch “Guardrails” (auf Deutsch „Leitplanken“) genannt) eine Linie um die gesamte Anwendung und die Dienste einschließlich der virtuellen Maschinen ziehen.

Mit der neuen Architektur von vSphere und der Integration von Kubernetes als Steuerungsebene können Namespaces als neue Verwaltungseinheit betrachtet werden.

Stellen Sie sich vor, dass Sie in Ihrem vCenter-Bestand Tausende von VMs haben, die Sie verwalten müssen. Nachdem Sie diese VMs in ihre logischen Anwendungen gruppiert haben, müssen Sie sich möglicherweise nur noch mit Dutzenden von Namespaces befassen.

Wenn Sie die Verschlüsselung für eine Anwendung aktivieren müssen, können Sie einfach auf eine Schaltfläche im Namespace in vCenter klicken und der Vorgang wird für Sie durchgeführt. Sie müssen sich nicht mehr mit einzelnen VMs befassen.

vSphere-Dienst für virtuelle Maschinen

Mit der Version vSphere 7 Update 2a stellte VMware den „VM Service” zur Verfügung, der die Kubernetes-native Bereitstellung und Verwaltung von VMs ermöglicht.

Für viele Unternehmen werden Legacy-Anwendungen nicht über Nacht modern. Sie werden zuerst hybrid, bevor sie vollständig modernisiert werden. Das bedeutet, dass wir eine Kombination aus Containern und virtuellen Maschinen haben, die die Anwendung bilden, und nicht nur Container finden. Ich bezeichne dies gegenüber meinen Kunden auch als hybride Anwendungsarchitektur. Sie können zum Beispiel eine containerisierte Anwendung haben, welche eine Datenbank nutzt, die in einer separaten VM gehostet wird.

Tanzu Mission Control – Namespace-Verwaltung

Tanzu Mission Control (TMC) ist ein VMware Cloud (SaaS) Service, der einen einzigen Kontrollpunkt für mehrere Teams bietet, um die Komplexität der Verwaltung von Kubernetes-Clustern über mehrere Clouds hinweg zu beseitigen.

Eine der Möglichkeiten Ihre Kubernetes-Ressourcen mit TMC zu organisieren und anzuzeigen, ist die Erstellung von “Workspaces”.

Mit Workspaces können Sie Ihre Namespaces in logischen Gruppen über Cluster hinweg organisieren, was die Verwaltung durch die Anwendung von Richtlinien auf Gruppenebene vereinfacht. So können Sie beispielsweise eine Zugriffsrichtlinie auf eine ganze Gruppe von Clustern (aus mehreren Clouds) anwenden, anstatt separate Richtlinien für jeden einzelnen Cluster zu erstellen.

Denken Sie einen Moment lang an die Sicherung und Wiederherstellung. TMC und das Konzept der Workspaces ermöglichen es Ihnen, Datenressourcen in Ihren Kubernetes-Clustern auf Namespace-Ebene zu sichern und wiederherzustellen.

Management und Betrieb mit einer neuen Anwendungsansicht! Zu Ihrer Information: VMware hat die Integration von Tanzu Mission Control und Tanzu Service Mesh im Dezember 2020 verkündet.

Service Mesh

Viele Anbieter, darunter auch VMware, haben erkannt, dass das Netzwerk die Struktur ist, die Microservices zusammenbringt, welche schlussendlich die Anwendung bilden. Mit modernisierten oder teilweise modernisierten Anwendungen, verschiedenen Kubernetes-Angeboten und einer Multi-Cloud-Umgebung wird die Realität von hybriden Anwendungen vorgefunden, die manchmal in mehreren Clouds laufen.

Dies ist der Moment, in dem Sie über die Konnektivität und Kommunikation zwischen den Microservices Ihrer Anwendung nachdenken müssen.

Eine der Hauptideen und -funktionen hinter einem Service Mesh war es, eine Service-zu-Service-Kommunikation für verteilte Anwendungen bereitzustellen, die in mehreren Kubernetes-Clustern laufen, welche wiederum in verschiedenen privaten oder öffentlichen Clouds gehostet werden.

Die Zahl der Kubernetes-Service-Meshes ist in den letzten Jahren rasant gestiegen und hat einen großen Hype erfahren. Kein Wunder, dass es verschiedene Service-Mesh-Angebote gibt:

• Istio
• Linkerd
• Consul
• AWS Apps Mesh
• OpenShift Service Mesh von Red Hat
• Open Service Mesh AKS Add-on (derzeit Preview auf Azure)

Istio

Istio ist wahrscheinlich das bekannteste Produkt auf dieser Liste. Für mich ist es definitiv das, worauf meine Kunden am meisten achten und worüber sie am meisten sprechen.

Service Mesh bringt eine neue Ebene der Konnektivität zwischen Diensten. Bei Service Mesh wird jedem Dienst ein Proxy vorangestellt; bei Istio beispielsweise geschieht dies über einen “Sidecar” (Seitenwagen) innerhalb des Pods. Die Architektur von Istio ist in eine auf Envoy basierende Datenebene (das Sidecar) und eine Steuerungsebene unterteilt, die die Proxys verwaltet. Mit Istio injizieren Sie die Proxys in alle Kubernetes-Pods im Mesh.

Wie Sie auf dem Bild sehen können, sitzt der Proxy vor jedem Microservice und die gesamte Kommunikation wird über ihn geleitet. Wenn ein Proxy mit einem anderen Proxy kommuniziert, sprechen wir von einem Service Mesh. Proxys verwalten auch den Datenverkehr, Fehler und Ausfälle (Wiederholungsversuche) und sammeln Metriken für die Observability-Zwecke.

Herausforderungen bei Service Mesh

Die Sache mit dem Service Mesh ist die, dass es zwar toll klingt, aber auch neue Herausforderungen mit sich bringt.

Die Installation und Konfiguration von Istio ist nicht ganz einfach und nimmt viel Zeit in Anspruch. Außerdem ist Istio in der Regel an einen einzigen Kubernetes-Cluster und damit an die Istio-Datenebene gebunden – und Unternehmen ziehen es in der Regel vor, ihre Kubernetes-Cluster unabhängig voneinander zu halten. Dies führt dazu, dass Sicherheit und Richtlinien an einen Kubernetes-Cluster oder einen Cloud-Anbieter gebunden sind, was wiederum zu Silos führt.

Istio unterstützt ein sogenanntes Multi-Cluster-Deployment mit einem Service-Mesh, das sich über Kubernetes-Cluster erstreckt.

Viele Kunden sprechen daher auch von einer besseren und einfacheren Verwaltbarkeit ohne Abhängigkeiten zwischen Clouds und verschiedenen Kubernetes-Clustern unterschiedlicher Anbieter.

Das ist der Moment, in dem Tanzu Service Mesh sehr interessant wird.

Tanzu Service Mesh (früher bekannt als NSX Service Mesh)

Tanzu Service Mesh, das auf VMware NSX aufbaut, ist ein Angebot, welches ein Service Mesh der Enterprise-Klasse bereitstellt. Es baut auf einer von VMware verwalteten Istio-Version auf.

Beim Onboarding eines neuen Clusters auf Tanzu Service Mesh stellt der Service eine von VMware signierte und unterstützte Istio-Version bereit. Diese Istio-Installation ist in jeder Hinsicht identisch mit der Upstream-Istio-Version, enthält aber zusätzlich einen Agenten, der mit der globalen Kontrollebene des Tanzu Service Mesh kommuniziert. Die Installation von Istio ist nicht besonders intuitiv, aber der Onboarding-Prozess von Tanzu Service Mesh vereinfacht den Prozess erheblich.

Der große Unterschied und der Wert, den Tanzu Service Mesh (TSM) mit sich bringt, ist seine Fähigkeit, Cluster- und Cloud-übergreifende Anwendungsfälle über Global Namespaces zu unterstützen.

Globale Namespaces (GNS)

Ja, noch eine andere Art von Namespace, aber die spannendste:

Ein Global Namespace ist ein einzigartiges Konzept in Tanzu Service Mesh und verbindet Ressourcen und Workloads zu einer virtuellen Einheit, die die Anwendung bilden. Jeder GNS ist eine isolierte Domäne, die eine automatische Service-Erkennung bietet und die folgenden Funktionen verwaltet, die unabhängig von ihrem Standort portiert werden:

• Identität: Jeder globale Namensraum hat seine eigene Zertifizierungsstelle (CA), die Identitäten für die Ressourcen innerhalb dieses globalen Namensraums bereitstellt.
• Erkennung (DNS): Der globale Namensraum steuert, wie eine Ressource eine andere lokalisieren kann und stellt ein Register zur Verfügung.
• Konnektivität: Der globale Namensraum definiert, wie die Kommunikation zwischen Ressourcen hergestellt werden kann und wie der Datenverkehr innerhalb des globalen Namensraums und außerhalb des globalen Namensraums zwischen den Ressourcen weitergeleitet wird.
• Sicherheit: Der globale Namensraum verwaltet die Sicherheit für seine Ressourcen. Insbesondere kann der globale Namensraum erzwingen, dass der gesamte Verkehr zwischen den Ressourcen mit der Authentifizierung Mutual Transport Layer Security (mTLS) verschlüsselt wird.
• Observability: Tanzu Service Mesh aggregiert Telemetriedaten, wie z. B. Metriken für Services, Cluster und Nodes, innerhalb des globalen Namensraums.

https://www.youtube.com/watch?v=M-Qwo4eVYMg

Anwendungsfälle

Das folgende Diagramm stellt das globale Namespace-Konzept und andere Teile in einer High-Level-Architekturansicht dar. Die Komponenten einer Anwendung sind in zwei verschiedenen Kubernetes-Clustern verteilt: Einer davon befindet sich vor Ort und der andere in einer öffentlichen Cloud. Der globale Namensraum schafft eine logische Sicht auf diese Anwendungskomponenten und bietet eine Reihe von Basisdiensten für die Komponenten.

Nehmen wir die Anwendungskontinuität als weiteres Beispiel für einen Anwendungsfall, so würden wir eine Anwendung in mehr als einem Cluster und möglicherweise in einer anderen entfernten Region für die Notfallwiederherstellung (DR) bereitstellen. Mit einem Load Balancer zwischen den Standorten um den Datenverkehr zu beiden Clustern zu leiten. Dies wäre ein Aktiv-Aktiv-Szenario. Mit Tanzu Service Mesh könnten Sie die Cluster in einem Global Namespace gruppieren und diesen so programmieren, dass der Datenverkehr im Falle eines Ausfalls automatisch umgeleitet wird.

Neben dem Anwendungsfall und der Unterstützung für Hochverfügbarkeit und Disaster Recovery über mehrere Zonen und Regionen hinweg können Sie auch Ausfallsicherheit mit automatischer Skalierung auf der Grundlage definierter Service-Level Objectives (SLO) für Multi-Cloud-Anwendungen bieten.

https://www.youtube.com/watch?v=583OZwsgQ28

VMware Modern Apps Konnektivitätslösung  

Im Mai 2021 stellte VMware eine neue Lösung vor, die die Fähigkeiten von Tanzu Service Mesh und NSX Advanced Load Balancer (NSX ALB, ehemals Avi Networks) zusammenführt – nicht nur für Container, sondern auch für VMs. Während Envoy von Istio nur auf Layer 7 arbeitet, bietet VMware mit NSX (Teil von TSM) und NSX ALB Layer-4- bis Layer-7-Services, die L4-Loadbalancing, Ingress-Controller, GSLB, WAF und End-to-End-Service-Transparenz umfassen.

Diese Lösung beschleunigt den Weg zur App-Modernisierung mit Konnektivität und besserer Sicherheit in hybriden Umgebungen und hybriden App-Architekturen.

Zusammenfassung

Eines kann ich mit Sicherheit sagen: Die Zukunft für Tanzu Service Mesh ist rosig!

Viele Kunden suchen nach Möglichkeiten, die Sicherheit (Verschlüsselung, Authentifizierung, Autorisierung) von einer Anwendung auf ein Service Mesh zu verlagern.

Ein großartiges Beispiel und Anwendungsfall aus der Finanzdienstleistungsbranche ist die Krypto-Agilität, wo ein “Krypto-Service-Mesh” (ein spezialisiertes Service-Mesh) Teil einer neuen Architektur sein könnte, die quantensichere Zertifikate bereitstellt.

Und wenn wir die Verschlüsselung, Berechnung, Authentifizierung usw. auslagern, dann gibt es möglicherweise weitere Anwendungsfälle für SmartNICs und Project Monterey.

Um mehr über Service Mesh und die Möglichkeiten von Tanzu Service Mesh zu erfahren, kann ich das Buch Service Mesh for Dummies von Niran Even-Chen, Oren Penso und Susan Wu empfehlen oder besuchen Sie meinen Blog cloud13.ch.

 

In diesem VMware DACH Blogbeitrag erfahren Sie mehr zu Kubernetes-fähigen Lösungen für Cloud-native Anwendungen.

Sie möchten bei VMware immer up to date sein? Dann folgen Sie VMware auf Twitter, XING, LinkedIn, Youtube & Podcast