Komplexe Container-Cluster managen

Wann ist ein Service Mesh sinnvoll?

| Autor / Redakteur: Owen Garrett * / Stephan Augsten

Mit zunehmender Komplexität der Applikation wird das Service Mesh zu einer realistischen Alternative zum Ansatz, einen Service nach dem anderen zu implementieren.
Mit zunehmender Komplexität der Applikation wird das Service Mesh zu einer realistischen Alternative zum Ansatz, einen Service nach dem anderen zu implementieren. (Bild: NGINX)

Immer öfter hört man, große Container-Implementierungen benötigten ein Service Mesh. Dabei betreiben Unternehmen ihre Applikationen schon seit Jahren erfolgreich auf Container-Plattformen – und das ohne Service Mesh. Wie lässt sich diese Unstimmigkeit auflösen?

Service Mesh ist ein brandaktuelles Thema. Im vergangenen Jahr schien es, als ob jede größere Container-Konferenz einen Schwerpunkt dafür vorgesehen hatte. Darüber hinaus sprechen Influencer der Branche stets von den bahnbrechenden Vorteilen dieser Technologie. Aber die Service-Mesh-Technologie noch nicht vollständig ausgereift.

Selbst das führende Implementierungswerkzeug, Istio, ist noch nicht für den unternehmensweiten Einsatz bereit. Es gibt bisher auch nur eine Handvoll erfolgreich laufender Implementierungen. Darüber hinaus existieren weitere Service-Mesh-Werkzeuge. Doch diese bekommen laut Branchen-Insidern nicht die Aufmerksamkeit, die sie verdienen. Im Folgenden beschäftigen wir uns mit der Frage, wann ein Service Mesh wirklich sinnvoll ist.

Einstieg mit Kubernetes

Service Mesh ist ein Meilenstein auf dem Weg, aber es ist nicht der Ausgangspunkt.

Kubernetes ist eine sehr leistungsfähige Plattform, die sich in der Bereitstellung von Container-Applikationen bewährt hat. Es bietet eine umfassende Netzwerkebene, die Service Discovery, Load Balancing, Health Checks, und Access Control vereint, um komplexe verteilte Applikationen zu unterstützen.

① Kubernetes bietet ein grundlegendes Layer-4-Netzwerk durch Service Discovery und Load Balancing. ② Der NGINX Ingress Controller übernimmt das Load Balancing externer Verbindungen zu Services, die im Kubernetes-Cluster laufen.
① Kubernetes bietet ein grundlegendes Layer-4-Netzwerk durch Service Discovery und Load Balancing. ② Der NGINX Ingress Controller übernimmt das Load Balancing externer Verbindungen zu Services, die im Kubernetes-Cluster laufen. (Bild: NGINX)

Diese Funktionen sind mehr als ausreichend für einfache Applikationen und für etablierte, containerbasierte Legacy-Anwendungen. Sie ermöglichen es Applikationen zuverlässig bereitzustellen, sie bei Bedarf zu skalieren, unerwartete Fehler zu umgehen und eine einfache Zugangskontrolle zu implementieren.

Kubernetes stellt in seiner API ein Ingress-Ressourcenobjekt zur Verfügung. Dieses Objekt definiert, wie auf ausgewählte Dienste von außerhalb des Kubernetes-Clusters zugegriffen werden kann, und ein Ingress-Controller implementiert diese Richtlinien. Für viele im Betrieb befindliche Applikationen bietet die Kombination aus Kubernetes und Ingress-Controller alle erforderlichen Funktionen.

Weitere Schritte für komplexere Applikationen

Ergänzung von Security, Monitoring und Traffic-Management, um Kontrolle und Transparenz zu optimieren.

Beim Verwalten von Applikationen im Betrieb benötigen die Teams manchmal eine bessere Kontrolle und Transparenz. Anspruchsvolle Applikationen können ein komplexes Netzwerkverhalten aufweisen, während häufige Änderungen im Betrieb zu einem erhöhten Risiko für die Stabilität und Konsistenz der Anwendung führen können. Es kann notwendig sein, den Datenverkehr zwischen den Komponenten zu verschlüsseln, wenn er auf einem gemeinsamen Kubernetes-Cluster ausgeführt wird.

Jede Anforderung kann wie folgt erfüllt werden:

  • Um verschlüsselten Datenaustausch zwischen den Services zu gewährleisten, kann für jeden Microservice ein mutual TLS (mTLS) mit SPIFFE oder eine gleichwertige Methode implementiert werden
  • Um Leistungs- und Zuverlässigkeitsprobleme zu identifizieren, kann jeder Microservice Prometheus spezifische Daten zur Analyse für Tools wie Grafana exportieren.
  • Um diese Probleme zu beheben, können OpenTracing Tracers in jeden Mikroservice integriert werden (mehrere Sprachen und Frameworks werden unterstützt).
  • Um erweiterte Lastausgleichsrichtlinien, Blue-Green- und Canary Deployment sowie Trennschalter zu implementieren, können Proxies und Load Balancer eingesetzt werden.

Einzelne Mikroservices können mit Prometheus Exporters, OpenTracing Tracers, mutual TLS und SPIFFE (POTS) erweitert werden. Proxies können bereitgestellt werden, ① um einzelne Services auszugleichen, oder ②, um ein zentrales Router Mesh bereitzustellen.
Einzelne Mikroservices können mit Prometheus Exporters, OpenTracing Tracers, mutual TLS und SPIFFE (POTS) erweitert werden. Proxies können bereitgestellt werden, ① um einzelne Services auszugleichen, oder ②, um ein zentrales Router Mesh bereitzustellen. (Bild: NGINX)

Einige dieser Techniken erfordern eine kleine Änderung in den einzelnen Services – zum Beispiel das Festlegen von Zertifikaten auf Container oder das Hinzufügen von Modulen für Prometheus und OpenTracing. NGINX Plus bietet dediziertes Load Balancing für kritische Services inklusive Service Discovery und API-getriebener Konfiguration, um Änderungen zu orchestrieren. Dabei implementiert das Router Mesh Schema in der NGINX Microservices Reference Infrastructure einen cluster-weiten Kontrollpunkt für den Datenverkehr.

Load Balancing, Service Discovery und API-gesteuerte Konfiguration für kritische Services ermöglichen die Durchführung von Änderungen. Fast jede containerbasierte Applikation in Betrieb verwendet heute solche Techniken, um die Kontrolle und Transparenz zu verbessern.

Warum kann ein Service Mesh dennoch sinnvoll sein?

Wenn sich die oben genannten Techniken im Betrieb bewährt haben, was bietet ein Service Mesh zusätzlich?

Jeder vorher beschriebene Schritt stellt eine Herausforderung für den Anwendungsentwickler und das Operations-Team dar. Für einzelne Services ist es relativ einfach, aber die Komplexität summiert sich. Ab einem gewissen Zeitpunkt werden umfangreiche und komplexe Anwendungen einen Punkt erreichen, an dem die Verbesserung eines Service nach dem anderen zu schwierig und nicht mehr skalierbar ist.

Genau dieses Problem verspricht das Service Mesh zu lösen. Das Ziel eines Service Mesh ist es, die erforderlichen Ressourcen auf standardisierte und transparente Weise für alle Services bereitzustellen und dabei für die Applikation völlig unsichtbar zu bleiben. Mit nur sehr wenigen Einsätzen im tatsächlichen Betrieb ist die Service Mesh-Technologie immer noch neu. Die ersten Implementierungen wurden auf Basis komplexer, hauseigener Lösungen entwickelt, die speziell auf die Bedürfnisse des einzelnen Anwenders zugeschnitten wurden.

In einem Service Mesh beinhaltet jeder Container einen eingebetteten Proxy, der den gesamten Datenverkehr für Ein- und Ausgang abfangen kann. Der Proxy übernimmt die Verschlüsselung, Überwachung und Rückverfolgung im Auftrag des Services und implementiert ein erweitertes Management für den Datenverkehr.
In einem Service Mesh beinhaltet jeder Container einen eingebetteten Proxy, der den gesamten Datenverkehr für Ein- und Ausgang abfangen kann. Der Proxy übernimmt die Verschlüsselung, Überwachung und Rückverfolgung im Auftrag des Services und implementiert ein erweitertes Management für den Datenverkehr. (Bild: NGINX)

Es zeichnet sich ein universellerer Ansatz ab, der als „Sidecar Proxy“-Muster bezeichnet wird. Dieser Ansatz setzt Layer-7-Proxies neben jeder einzelnen Service-Instanz ein. Diese Proxies erfassen den gesamten Netzwerk-Datenverkehr und bieten konsistent zusätzliche Ressourcen, wie mutual TLS, Tracing, Metriken, Traffic Control und andere an.

Anbieter und Open-Source-Projekte sind dabei, stabile, funktionale und einfach zu bedienende Implementierungen zu realisieren. 2019 ist mit ziemlicher Sicherheit das „Jahr des Service Mesh“, in dem diese vielversprechende Technologie den Punkt erreichen wird, an dem einige Implementierungen wirklich betriebsreif für Universalanwendungen sein werden.

Was ist nun zu tun?

Es ist für einzelne Unternehmen noch viel zu früh, um zu einer der anfänglichen Service-Mesh-Implementierungen überzugehen. Ausnahmen sind, wenn sie die Grenzen ihrer bis dahin genutzten Lösungen erreichen und deshalb eine schnelle und kurzfristige Lösung benötigen.

Mit zunehmender Komplexität der Applikation wird das Service Mesh zu einer realistischen Alternative zum Ansatz, einen Service nach dem anderen zu implementieren.
Mit zunehmender Komplexität der Applikation wird das Service Mesh zu einer realistischen Alternative zum Ansatz, einen Service nach dem anderen zu implementieren. (Bild: NGINX)

Der Reifegrad der Technologie und das rasante Tempo des Wandels der Service Mesh-Implementierungen bringen bei deren Einsatz große Risiken und Kosten mit sich. Mit zunehmender Reife der Technologie sinken die Kosten und Risiken dagegen, sodass der Wendepunkt für die Einführung von Service Mesh immer näher rückt.

Durch das Fehlen eines stabilen, ausgereiften Service Meshs sollen sich Unternehmen aber nicht von Initiativen, die sie aktuell in Betracht ziehen, abhalten lassen. Wie wir gesehen haben, bieten Kubernetes und andere Orchestrierungsplattformen eine umfangreiche Funktionalität. Zudem kann das Hinzufügen anspruchsvoller Funktionen auch über vertraute Pfade erfolgen.

Owen Garrett, Head of Products bei NGINX.
Owen Garrett, Head of Products bei NGINX. (Bild: NGINX)

Vorerst sollten Unternehmen auf bewährte Lösungen wie Ingress Router und interne Load Balancer setzen. Sie werden es merken, sobald sie den Punkt erreichen, an dem es an der Zeit ist, darüber nachzudenken, eine Service Mesh-Implementierung zum Einsatz zu bringen.

* Owen Garrett ist Senior Director of Product Management bei NGINX.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45981562 / Container & Virtualisierung)