Service Mesh für Microservices
E-Book, Deutsch, 268 Seiten
ISBN: 978-3-96010-412-4
Verlag: O'Reilly
Format: EPUB
Kopierschutz: 6 - ePub Watermark
Lee Calcote ist Wegbereiter für innovative Produkte und Technologien, der sich leidenschaftlich dafür einsetzt, Ingenieure mit Lösungen zu versorgen. Als Gründer von Layer5 steht er an der Spitze der Cloud-native-Bewegung. Lee ist als Docker Captain, Cloud Native Ambassador und Mentor für Summer of Code von Google aktiv. Zack Butcher ist Gründungsingenieur bei Tetrate und entscheidender Mitgestalter des Istio-Projekts. Bei Tetrate bekleidet er viele Funktionen - unter anderem ist er als Systemarchitekt, im Vertrieb, als Autor und als Redner tätig.
Weitere Infos & Material
KAPITEL 1
Einführung in Service Mesh
Was ist ein Service Mesh?
Service Meshes bieten richtlinien- und netzwerkbasierte Dienste für Workloads, die über ein Netzwerk verbunden sind, indem sie das gewünschte Verhalten des Netzwerks angesichts sich ständig ändernder Bedingungen und Topologie durchsetzen. Zu den Bedingungen, die sich ändern können, gehören Last, Konfiguration, Ressourcen (einschließlich derjenigen, die die Infrastruktur und die Anwendungstopologie von kommenden und gehenden Intracluster- und Intercluster-Ressourcen beeinflussen) und die bereitgestellten Workloads. Grundlagen Service Meshes bilden eine adressierbare Infrastrukturschicht, die es Ihnen ermöglicht, sowohl vorhandene monolithische (oder andere) Workloads zu modernisieren als auch die zunehmende Verbreitung von Microservices in den Griff zu bekommen. Sie sind in monolithischen Umgebungen vorteilhaft, doch ihre rasante Ausbreitung ist unserer Ansicht nach vor allem dem Übergang hin zu Microservices und Containern geschuldet – d.h. dem Cloud-native Ansatz zum Entwurf von skalierbaren, unabhängig bereitgestellten Diensten. Microservices haben die ursprüngliche interne Kommunikation zwischen Anwendungen explosionsartig in ein Geflecht von Service-to-Service-Remoteprozeduraufrufen (Remote Procedure Calls, RPCs) verwandelt, die über Netzwerke transportiert werden. Zu den vielen Vorzügen von Microservices gehören die freie Sprach- und Technologieauswahl über unabhängige Service-Teams hinweg – Teams, die schnell neue Features schaffen, indem sie iterativ und kontinuierlich Software (in der Regel als Service) bereitstellen. Da das Gebiet der Vernetzung so riesig ist, dürfte es nicht überraschen, dass es viele subtile, fast unmerkliche Unterschiede zwischen ähnlichen Konzepten gibt. Im Kern bieten Service Meshes ein entwicklergetriebenes Services-first-Netzwerk: eines, das vorrangig darauf abzielt, es Anwendungsentwicklern zu ersparen, sich in ihrem Code mit Netzwerkproblemen (z.B. Resilienz) herumschlagen zu müssen, und eines, das Betreiber in die Lage versetzt, Netzwerkverhalten, Knotenidentität und Verkehrsfluss über Richtlinien deklarativ zu definieren. Dies mag wie die Reinkarnation von Software-defined Networking (SDN) aussehen, doch Service Meshes unterscheiden sich hier vor allem dadurch, dass sie einen entwicklerzentrierten Ansatz betonen und keinen Ansatz, bei dem der Netzwerkadministrator im Mittelpunkt steht. Zum größten Teil sind die heutigen Service Meshes vollkommen softwarebasiert (obwohl hardwarebasierte Implementierungen vielleicht auch noch kommen werden). Wenngleich der Begriff Intent-based Networking (absichtsbasierte Vernetzung) vor allem in physischen Netzwerken verwendet wird, ist es angesichts der von Service Meshes gebotenen deklarativen richtlinienbasierten Steuerung fair, ein Service Mesh mit einem Cloud-native SDN zu vergleichen. Abbildung 1-1 zeigt einen Überblick über die Service-Mesh-Architektur. (Was es heißt, Cloud-native zu sein, umreißen wir in Kapitel 2.) Abbildung 1-1: Wenn es keine Control Plane gibt, ist es auch kein Service Mesh. Service Meshes werden mithilfe von Service Proxys erstellt. Service Proxys der Data Plane (Datenebene) übertragen den Datenverkehr. Der Verkehr wird transparent mit iptable-Regeln im Pod-Namespace abgefangen. Die einheitliche Infrastrukturschicht wird in Kombination mit Service-Deployments allgemein als ein Service Mesh bezeichnet. Istio verwandelt ungleichartige Microservices in ein integriertes Service Mesh, indem ein Proxy systemisch zwischen alle Netzwerkpfade injiziert wird, die Proxys untereinander bekannt gemacht werden und diese unter eine zentralisierte Steuerung kommen. Auf diese Weise entsteht ein Service Mesh. Auf ein Service Mesh zusteuern
Ob die Herausforderung, der Sie sich stellen müssen, eine Flotte von Microservices ist oder Sie vorhandene nicht containerisierte Services modernisieren müssen – Sie steuern möglicherweise auf ein Service Mesh zu. Je mehr Microservices bereitgestellt werden, desto größer werden diese Herausforderungen. Clientbibliotheken: die ersten Service Meshes? Um sich der komplexen Aufgabe zu stellen, Microservices zu verwalten, verwenden manche Unternehmen Clientbibliotheken als Frameworks, um Implementierungen zu standardisieren. Diese Bibliotheken werden zu den ersten Service Meshes gezählt. Abbildung 1-2 veranschaulicht, wie es Ihre Architektur bei Verwendung von Bibliotheken erfordert, die Grundstrukturen der gewählten Bibliothek(en) mit Anwendungscode zu verwenden oder zu erweitern. Zusätzlich muss Ihre Architektur auf die potenzielle Verwendung von mehreren sprachspezifischen Frameworks und/oder Anwendungsservern ausgerichtet sein, um sie ausführen zu können. Abbildung 1-2: Services-Architektur, die Clientbibliotheken in Verbindung mit Anwendungslogik verwendet Die beiden Vorteile der Erstellung von Clientbibliotheken sind, dass die konsumierten Ressourcen für jeden einzelnen Service lokal zu Buche schlagen und dass Entwickler die Möglichkeit bekommen, selbst zu entscheiden, ob sie eine vorhandene Bibliothek wählen oder eine neue sprachspezifische Bibliothek aufbauen wollen. Mit der Zeit sind aber aufgrund der Nachteile bei Verwendung von Clientbibliotheken die Service Meshes entstanden. Ihr markantester Nachteil ist die enge Kopplung von Infrastrukturbelangen mit Anwendungscode. Das uneinheitliche sprachspezifische Design von Clientbibliotheken macht ihre Funktionalität und ihr Verhalten inkonsistent. Das führt zu schlechten Beobachtungseigenschaften, maßgeschneiderten Praktiken, um Dienste zu erweitern, die sich mehr oder weniger gegenseitig steuern lassen, und nicht zuletzt zu Beeinträchtigungen der Sicherheit. Für Unternehmen wird es möglicherweise kostspielig, diese sprachspezifischen Resilienzbibliotheken umfassend einzusetzen, und es kann zum einen schwierig sein, sie in Brownfield-Anwendungen einzugliedern, und zum anderen völlig unpraktikabel, sie in bestehende Architekturen zu integrieren. Vernetzung ist schwierig. Eine Clientbibliothek zu erstellen, die Clientkonflikte eliminiert, indem sie Jitter-Effekte einbringt und nach einem Exponential-Backoff-Algorithmus das Timing für den nächsten Retry-Versuch berechnet, ist nicht unbedingt einfach, und das gilt ebenso für den Versuch, das gleiche Verhalten über verschiedene Clientbibliotheken (mit variierenden Sprachen und Versionen dieser Bibliotheken) sicherzustellen. Es ist schwierig, Upgrades von Clientbibliotheken in großen Umgebungen zu koordinieren, da es bei Upgrades erforderlich ist, den Code zu ändern, ein neues Release der Anwendung auszurollen und möglicherweise die Anwendung vorübergehend außer Betrieb zu nehmen. Abbildung 1-3: Services-Architektur mit Service Proxys, die von der Anwendungslogik entkoppelt sind Abbildung 1-3 zeigt, dass Anwendungen mit einem Service Proxy neben jeder Anwendungsinstanz keine sprachspezifischen Resilienzbibliotheken mehr für Circuit Breaker (Sicherung), Timeouts, Retrys, Service Discovery, Lastverteilung usw. haben müssen. Service Meshes scheinen das Versprechen einzulösen, dass Unternehmen, die Microservices implementieren, endlich den Traum verwirklichen können, die besten Frameworks und die beste Sprache für ihre individuellen Aufgaben zu verwenden, ohne sich über die Verfügbarkeit von Bibliotheken und Mustern für jede einzelne Plattform Gedanken machen zu müssen. Wozu brauche ich es? Jetzt denken Sie vielleicht: »Ich habe einen Container-Orchestrator. Wozu brauche ich eine weitere Infrastrukturschicht?« Bei der Einbeziehung von Microservices und Containern stellen Container-Orchestratoren einen Großteil dessen bereit, was die Cluster (Knoten und Container) benötigen. Sie konzentrieren sich weitgehend auf Planung, Erkennung und Integrität, hauptsächlich (zwangsläufig) auf einer Infrastrukturebene, sodass Microservices mit unerfüllten Bedürfnissen auf Service-Ebene zurückbleiben. Ein Service Mesh ist eine dedizierte Infrastrukturschicht, die für eine sichere, schnelle und zuverlässige Kommunikation von Service zu Service sorgen soll, wobei sie sich auf einen Container-Orchestrator oder die Integration mit anderen Service-Discovery-Systemen stützt. Service Meshes lassen sich zwar als separate Schicht auf Container-Orchestratoren bereitstellen, setzen diese aber nicht voraus, so wie die Komponenten der Control und Data Planes unabhängig von der containerisierten Infrastruktur bereitgestellt werden können. In Kapitel 3 sehen wir uns an, wie ein Knotenagent (einschließlich eines Service Proxys) als Komponente der Data Plane in Nichtcontainer-Umgebungen bereitgestellt wird. Das Service Mesh Istio wird üblicherweise à la carte übernommen. Mitarbeiter von Organisationen, mit...
