Service Meshes Flashcards
Was sind die Funktionen eines Service Meshes?
• Meshes ermöglicht es den Entwicklern, Herausforderungen in den Bereichen Sicherheit, Kommunikation und Logging/Monitoring aus der Hand zu nehmen und zentral zu verwalten
Warum brauchen wir Service Mesh?
• Neue Probleme und Challenges in MS Architektur die bei Monolith so nicht vorhanden waren
- Challenge: Kommunikation:
- Jeder MS hat seine eigene Business Logik (bsp. Zahlung, registierung etc)
- Die Services müssen untereinander kommunizieren (Problem Kommunikation der Services untereinander)
- Muss wissen, wer mit wem kommunizieren soll, was kommuniziert werden soll zwischen den Services usw.
- Es braucht also eine Art Anleitung wie die Services Kommunizieren sollen, jeder MS muss dies haben
- Challenge: Sicherheit
- Häufig so, dass es eine Firewall gibt, die Anfragen von außen regelt oder einen Proxy
- Sicherheit außerhalb des Clusters, aber sobald eine Anfrage sich im Cluster befindet, ist die Kommunikation unsicher
- MS kommunizieren über http oder anderes unsicheres Protokoll
- Auch kann aktuell jeder Service mit jedem anderen Service im Cluster kommunizieren
- Sobald sich Angreifer also Zugriff auf Cluster verschafft hat, kann dieser dort alles machen, da dort keine zusätzlichen Sicherheitsmaßnahmen sind
- Besonders bei sensiblen Nutzerdaten kann das natürlich zum Problem werden
- Challenge: Retry-Logik
- Wenn man MS nicht erreicht oder es Probleme bi der Erreichbarkeit des jeweiligen MS gibt, macht eine Retry-Logik den ganzen Service robuster und weniger fehleranfällig
- Mit Retry-Logik kann man Regeln erstellen wie und in welchen Fällen man die Anfrage an den MS wiederholen möchte und was zu tun ist, wenn dieser nicht erreichbar ist
- Challenge: Metriken und Logs
- Möchte überwachen wie die Services sich verhalten
- Bsp. Welche http Fehler bekommt man, wie viele anfragen bekommen die jeweiligen MS?, wie lange dauert eine Anfrage etc.
- Man müsste es jetzt so machen, da jeweils Team für MS zuständig ist, dass dieses Team all diesen Code jeweils implementiert und konfigurieren
- Diese arbeiten also in der Zeit nicht am Service selbst sondern müssen Netzwerk und Kommunikationslogik für ihren jeweiligen Service programmieren
• Erläutere das Sidecar-Pattern.
Ein Service Mesh macht intensiven Gebrauch vom Sidecar-Pattern. Der Begriff ist abgeleitet vom Beiwagen eines Motorrads. Wenn Funktionen, die von mehreren Services benötigt werden, in eine Anwendung ausgelagert werden, wird diese als Sidecar bezeichnet. Das Sidecar wird jedem Service zur Seite gestellt. Typische Funktionen, die auf diese Weise ausgelagert werden, sind Ver- bzw. Entschlüsselung, Authentifizierung oder das Sammeln und Bereitstellen von Metriken. Die Kommunikation zwischen Service und Sidecar findet über Standard-Netzwerkprotokolle statt.
Ein Sidecar kann damit unabhängig von Implementierungsdetails des Service genutzt werden. Häufig besteht ein Sidecar aus einem Service Proxy, durch den automatisch alle Netzwerkverbindungen geleitet werden. Abb. 1 stellt die Nutzung von Bibliotheken und die Auslagerung in Sidecars gegenüber.
Mit einem Sidecar wird eine Anwendung also erweitert, ohne dass sie davon Kenntnis haben oder verändert werden muss. Auch in einem Service Mesh wird neben jeden Microservice ein solcher Service Proxy als Sidecar platziert. Die Gesamtheit aller Service Proxys wird in einem Service Mesh als Data Plane bezeichnet. Dieser Begriff ist darauf bezogen, dass jegliche Kommunikation zwischen den Services über die Service Proxys stattfindet, die Metadaten zum Netzwerkverkehr erfassen und bereitstellen.
Das Konzept von Sidecars gab es schon lange vor dem Service Mesh. Die Sidecars wurden manuell bereitgestellt und das Netzwerk so konfiguriert, dass Anfragen den Service Proxy durchlaufen. Wenn jedoch Änderungen an der Konfiguration des Sidecars vorgenommen werden sollen, ist dies – insbesondere in größeren Systemen – mit viel manueller Arbeit verbunden. Ein Service Mesh kann als eine Erweiterung des Sidecar-Patterns aber vor allem als dessen Automatisierung betrachtet werden.
- Es werden CRDs erstellt
- Istiod wandelt diese übergeordneten Regeln in envoy spezifische Regeln
- Die Konfiguration wird in Proxy-Sidecars propagiert
- Proxys können untereinander kommunizieren
Wozu dienen die Data Plane und die Control Plane?
An Istio service mesh is logically split into a data plane and a control plane.
The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices. They also collect and report telemetry on all mesh traffic.
The control plane manages and configures the proxies to route traffic.
• Was sind Vorteile und Nachteile von Service Meshes?
Vorteile:
• Erleichterung der Kommunikation zwischen verschiedenen Microservices oder sogar Containern
• Einfachere Diagnose von Kommunikationsfehlern, da diese auf der eigenen Infrastrukturschicht auftreten und somit auch besser überwacht werden können.
• Ermöglicht schnelleres Entwickeln, Testen und Bereitstellen einer Anwendung.
• Bietet uns einige sofort einsatzbereite Sicherheitsfunktionen wie Verschlüsselung, Authentifizierung und Autorisierung.
• Sidecar-Container, die neben der eigentlichen Anwendung platziert werden, bieten Einblicke in die Anwendung und den Datenverkehr ohne programmatische Verbindungen.
• Bietet die Möglichkeit, moderne Deployment-Strategien ohne großen Aufwand zu nutzen.
Nachteile:
• Mit den zusätzlichen Sidecar- und Verwaltungskomponenten haben Sie natürlich mehr Laufzeitartefakte, die ebenfalls Ressourcen benötigen.
• Ebenso hat jede Anwendung mit dem Routing des Datenverkehrs und der Verwendung eines Service Mesh ein paar Hürden mehr. Grund dafür ist das Sidecar, das bei jedem Aufruf der Anwendung durchlaufen werden muss.
• Erhöhte Komplexität durch eine zusätzliche Infrastrukturschicht.
• Erforderliches Fachwissen: Das Hinzufügen eines Service Mesh wie Istio zu einem Orchestrator wie Kubernetes erfordert oft, dass Betreiber Experten in beiden Technologien werden.
• Langsamkeit: Service Meshes sind eine invasive und komplizierte Technologie, die eine Architektur erheblich verlangsamen kann.
• Einführung einer Plattform: Die Invasivität von Service Meshes zwingt sowohl Entwickler als auch Betreiber dazu, sich an eine höchst eigensinnige Plattform anzupassen und sich an ihre Regeln zu halten.
What is a service mesh?
Ein Service-Mesh ist eine dedizierte Infrastrukturebene, die in eine Anwendung integriert ist und die Service-to-Service-Kommunikation in einer Microservices-Architektur steuert. Es steuert die Übermittlung von Dienstanforderungen an andere Dienste, führt einen Lastausgleich durch, verschlüsselt Daten und erkennt andere Dienste.
A service mesh is a dedicated infrastructure layer built into an application that controls service-to-service communication in a microservices architecture. It controls the delivery of service requests to other services, performs load balancing, encrypts data, and discovers other services.
Although you can code the logic that governs communication directly into the microservices, a service mesh abstracts that logic into a parallel layer of infrastructure using a proxy called a sidecar, which runs alongside each service.
Sidecar proxies make up a service mesh’s data plane, which manages the exchange of data between services. Management processes make up the control plane, which coordinates the proxies’ behavior. The control plane also provides an API so operators can easily manage traffic control, network resiliency, security and authentication, and custom telemetry data for each service.
Why do you need a service mesh?
In general, your organization can benefit from a service mesh if you have large-scale applications composed of many microservices. As application traffic grows, requests between these services can increase exponentially, requiring sophisticated routing capabilities to optimize the flow of data between the services and ensure the application continues to perform at a high level.
From a secure communications standpoint, service meshes are useful for managing the secure TLS (mTLS) connections between services.
Because service meshes manage the communication layer, they allow developers to focus on adding business value with each service they build, rather than worrying about how each service communicates with all other services.
For DevOps teams that have an established production CI/CD pipeline, a service mesh can be essential for programmatically deploying apps and application infrastructure (Kubernetes) to manage source code and test automation tools like Git, Jenkins, Artifactory, or Selenium. A service mesh enables DevOps teams to manage their networking and security policies through code.
Nenne zwei Service Mesh Produkte. Worin unterscheiden sie sich?
https://medium.com/cloudzone/k8s-service-mesh-linkerd-or-istio-4bb650d51bc6
Istio ist viel komplexer als Linkerd, da es versucht, weitaus mehr Probleme zu lösen als Linkerd. Linkerd hingegen hat eine sehr gezielte Reihe von Problemen, die es löst, wodurch es weniger komplex wird.
Linkerd verwendet einen linkerd2-Proxy, einen leichten, in Rust integrierten Proxy, der sehr schnell und nur für diesen Zweck ist.
Istio verwendet Envoy, ein Open-Source-Projekt von Lyft, als Proxy. Envoy ist im Vergleich zum Proxy von Linkerd komplex und schwer, da es als Allzweck-Proxy entwickelt wurde, um eine Vielzahl von Problemen wie Lastenausgleich, Header-Umschreibung, Ratenbegrenzung, Reverse-Proxy usw. zu lösen.
Mit Egress können Sie den Datenverkehr steuern, der den Cluster verlässt. Istio bietet eine Möglichkeit, den ausgehenden Datenverkehr mithilfe von virtuellen Dienstobjekten und Gateways zu steuern. Die Egress-Implementierung in Linkerd ist jedoch nicht einfach und kann nur mit DNS und DTAB implementiert werden.
• Nenne ein Beispiel, in dem das Routing-Feature sinnvoll ist.
Routing rules in the virtual service tell Red Hat OpenShift Service Mesh how to send the traffic for the virtual service to appropriate destinations. Route destinations can be versions of the same service or entirely different services.
Mit verschiedenen crds in yaml dateien kann das Verkehrsrouting zwischen den Microservies definiert werden, z. B. wer mit anderen kommunizieren kann etc.
Anfrage kommt von Benutzer mit gewisser Länder - ID rein, kann dann festlegen z.b auf welches Länderspezisfischen Service weitergeleitet wird
• Beschreibe die Funktionsweise eines Resilienz-Features.
Durch die verteilte Data Plane aus Service Proxys und die zentrale Control Plane, die diese konfiguriert und Daten verarbeitet, kann ein Service Mesh viele Funktionen implementieren:
Transparenz: Monitoring, Logging und Tracing
Resilienz: Timeouts, Retrys, Circuit Breaking, Fault Injection
Routing: A/B-Testing, Canary Releasing
Sicherheit: Authentifizierung, Verschlüsselung und Autorisierung
Was sind Alternativen zu Service Meshes, wenn ich diese nicht einsetzen möchte?
Und auch wenn es Microservices sein sollen, sollte die Art der Integration sorgfältig ausgewählt werden. Je nach Zielen und Anforderungen können Feeds oder Message Queues als Alternativen zu synchronen Aufrufen in Erwägung gezogen werden.
