Microservices-Architekturen lösen einige Problemstellungen auf, führen jedoch auch einige neue ein: Applikationen in unabhängige Services aufzusplitten, vereinfacht es zwar, diese zu entwickeln, zu aktualisieren und zu skalieren. Aber es müssen auch bedeutend mehr bewegliche Teile verbunden und abgesichert werden. Sämtliche Netzwerk-Services wie Load Balancing, Traffic Management, Authentifizierung und Autorisierung zu managen, kann sich deshalb äußerst komplex gestalten.

Der vernetzte Raum zwischen den Services in Ihrem Kubernetes-Cluster hat auch einen Namen: Service Mesh. Ein solches stellt Google mit dem Open-Source-Projekt Istio zur Verfügung. Im Folgenden betrachten wir die Komponenten und Vorteile dieser quelloffenen Service-Mesh-Plattform.

Zur Orientierung zunächst ein kurzes Erklärstück in Videoform:

Istio Service Mesh - Komponenten

Istio fungiert als Service Mesh, indem es zwei grundlegende Architekturkomponenten für Ihr Cluster bereitstellt: eine Data Plane (Datenebene) und eine Control Plane (Steuerungsebene).

• Die Data Plane wickelt den Netzwerkverkehr zwischen den Services im Mesh über eine Gruppe von Netzwerk-Proxies ab. Im Fall von Istio läuft das über das Open-Source-Projekt Envoy.

• Die Control Plane bildet ein Services namens Istiod. Dieser kann für Service-Discovery- und -Management-Zwecke eingesetzt werden und generiert zudem die Zertifikate, die für eine sichere Kommunikation auf dieser Ebene nötig sind.

Eine relativ neue Istio-Funktion ist der sogenannte Ambient-Modus, der ein Istio-Deployment möglich macht, ohne jeder Kubernetes-App einen Envoy-Proxy zur Seite zu stellen. Darüber hinaus bietet Istio auch APIs, um diese Dienste zu steuern. Diese fallen in verschiedene Kategorien, die wir Ihnen nachfolgend vorstellen.

• Virtual Services ermöglichen es, Regeln dafür zu definieren, wie der Datenverkehr geroutet wird. Dabei kann jeder Virtual Service dazu genutzt werden, den Traffic an einen tatsächlichen Service im Mesh zu leiten. Wenn Sie beispielsweise zwei Implementierungen für eine bestimmte API im Rahmen eines A/B-Tests überprüfen wollen, können Sie jeweils eine Hälfte des Datenverkehrs an die unterschiedlichen API-Versionen weiterleiten.

• Destination Rules steuern, was mit dem Datenverkehr geschieht, nachdem er durch einen Virtual Service geleitet wurde. So lässt sich beispielsweise realisieren, dass Traffic der an unterschiedlichen Ports aufläuft auch unterschiedlichen Load-Balancing-Richtlinien unterliegt.

• Gateways managen den gesamten ein- und ausgehenden Traffic des Service Mesh - inklusive Load Balancing und L4-L6-Netzwerkprotokollierungsmaßnahmen. Es ist auch möglich, einen Virtual Service an ein Gateway zu koppen, um den Datenfluss zu kontrollieren. Als Ingress-Controller können in Istio der NGINX-Webserver und dessen Proxysystem verwendet werden. Auf diese Weise können die NGINX-Funktionen für erweitertes Load Balancing und Traffic Routing genutzt werden.

• Service Entries ermöglichen, die Registry von Istio um um bekannte Services zu erweitern. Ein registriertes Dienst wie eine externe API wird so wie ein Bestandteil des Istio-Mesh behandelt (auch wenn das eigentlich nicht der Fall ist).

• Sidecars unterstützen bei der Konfiguration von Istio, Beispielsweise wenn es um Envoy-Proxies geht, die standardmäßig so konfiguriert sind, dass sie eingehenden Traffic bei allen Ports und ausgehenden Traffic für jeden anderen Workload innerhalb des Mesh ermöglichen.

Was das Istio Service Mesh bringt

Mit seinem Open-Source-Projekt kann Google Anwenderunternehmen zahlreiche Benefits erschließen. Dazu zählen unter anderem:

• Abstraktion ist der wertvollste Benefit von Istio: Die quelloffene Lösung ermöglicht, die Komplexität eines Service Mesh "auf Distanz zu halten". Sämtliche Änderungen am Mesh lassen sich programmatisch über entsprechende Befehle vornehmen - statt eine Vielzahl von Komponenten händisch zu konfigurieren und darauf zu hoffen, dass alles ordnungsgemäß abläuft. Mit dem Mesh verbundene Services müssen zudem nicht "von innen" umprogrammiert werden, um neuen Netzwerk-Richtlinien gerecht zu werden. Und auch die Bereiche zwischen den Diensten müssen nicht mehr direkt angefasst werden.

• Nicht-destruktive oder vorläufige Änderungen an der Netzwerkkonfiguration des Clusters vornehmen zu können, ist ein weiterer Vorteil: Wenn Sie ein neues Netzwerklayout ganz oder teilweise einführen möchten oder die aktuelle Konfiguration mit einer potenziellen zukünftigen vergleichen möchten, ist das mit Googles quelloffener Plattform möglich - und zwar top down. Sämtliche Änderungen lassen sich dabei auch wieder rückgängig machen, falls sie sich als untauglich erweisen.

• Observability zählt ebenfalls zu den Istio-Benefits: Die Plattform liefert detaillierte Statistiken und Reportings darüber, was zwischen Containern und Cluster-Knoten vor sich geht. Sollten dabei unvorhergesehene Probleme auftauchen, lässt sich das im Handumdrehen analysieren.

• Auch gängige Patterns lassen sich mit Googles Service-Mesh-Plattform umsetzen. Beispielsweise das Circuit-Breaker-Pattern - eine Methode, um zu verhindern, dass ein Service mit Anfragen bombardiert wird. Istio bietet dieses und andere Patterns im Rahmen seiner Standardbibliothek im Bereich Richtliniendurchsetzung.

• Davon abgesehen ist Istio dank offener Standards auch plattformunabhängig - obwohl es relativ eng mit Kubernetes integriert. Die Service-Mesh-Plattform kann als Standalone-Lösung auf individuellen Systemen oder auch auf Orchestrierungs-Lösungen wie Mesos und Nomad eingesetzt werden.

Erste Schritte mit Googles Istio

Falls Sie bereits einschlägige Kubernetes-Erfahrungen gesammelt haben, empfiehlt es sich, Istio mit einem (nicht produktiven) Cluster und Ihrer bevorzugten Bereitstellungsmethode zu testen. Damit können Sie eine Beispiel-Applikation erstellen, um gängige Funktionalitäten zu testen und grundlegende Erfahrungen mit der Service-Mesh-Plattform zu sammeln, bevor Sie sie in der Produktion einsetzen.

Red Hat, das sich im Rahmen seines OpenShift-Projekts ebenfalls an Istio beteiligt hat, hat einige Tutorials im Angebot, die Sie durch gängige Deployment- und Management-Szenarien führen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.