Istio, Linkerd und Co. im Vergleich: Welches Service Mesh passt zu mir?

Service Meshes sind der nächste Schritt in der Microservices-Infrastruktur: Sie lösen lästige Probleme wie Observability, Routing, Resilience und Security. Lange Zeit stand Istio fast synonym für Service Meshes. Mittlerweile gibt es eine Vielzahl anderer Optionen, die häufig unter dem Radar bleiben.

Wie findet man das richtige Mesh für das Projekt? Und was sind überhaupt wichtige Eigenschaften eines Service Mesh?

Dieser Talk soll helfen, den Auswahlprozess zu verkürzen. Es werden nicht nur die Features im Detail verglichen, sondern auch Eigenschaften wie Usability und Performance.

Kurz gesagt: Alle, die sich fragen, ob oder welches Service Mesh sie brauchen, sind genau richtig in dieser Session.

Transcript

1. Istio, Linkerd und Co. im Vergleich Welches Service Mesh passt zu mir? Jörg Müller @joergm Hanna Prinz @HannaPrinz
2. Hanna Prinz Consultant innoQ Deutschland GmbH hanna.prinz@innoq.com @HannaPrinz - Software Development - DevOps, Kubernetes, Service Mesh
3. Jörg Müller Principal Consultant innoQ Deutschland GmbH joerg.mueller@innoq.com @joergm - architecture, development, DevOps - focus on platform & infrastructure
4. Was ist ein Service Mesh?
5. Microservices sind verteilte Systeme Microservice Timeout Retry Routing und Discovery Verschlüsselung Microservice Authentifizierung / Autorisierung Circuit Breaker Metriken Logs 5 @HannaPrinz @joergm @INNOQ
6. Libraries können helfen Microservice Microservice Lib Lib 6 @HannaPrinz @joergm @INNOQ
7. Kubernetes Pod Pod Kubernetes hilft auch Microservice Microservice Service 7 @HannaPrinz @joergm @INNOQ
8. Service Mesh Ansatz Microservice Proxy Microservice Proxy Control Plane Metriken Konfiguration 8 @HannaPrinz @joergm @INNOQ
9. Infrastruktur-Services Service Mesh Architektur Microservice 1 Microservice 2 Proxy Proxy Control Plane App Kubernetes API Anwendung Data Plane Control Plane Infrastruktur 9 @HannaPrinz @joergm @INNOQ
10. Ist ein Service Mesh überhaupt sinnvoll?
11. Oft lautet die Antwort: Nein
12. Wie viele Services? wenige viele(>~10) nur wenn bestimmte Features anders schwer zu realisieren sind (siehe weiter unten) 12 @HannaPrinz @joergm @INNOQ
13. Vielfalt der Technologien? niedrig Hoch Libraries können ein gute Alternative sein 13 @HannaPrinz @joergm @INNOQ
14. Überwiegend synchrone Kommunikation? Nein Ja Wahrscheinlich bringt ein Service Mesh wenig Mehrwert 14 @HannaPrinz @joergm @INNOQ
15. Ist Kubernetes im Einsatz? Nein Ja Die Auswahl der Lösungen wird erheblich eingeschränkt 15 @HannaPrinz @joergm @INNOQ
16. Wie dynamisch ändern sich Services? (Versionen & Skalierung) selten häufig Statische Konfiguration kann ausreichend sein & Service Meshes sollten vermutlich nicht der Fokus sein 16 @HannaPrinz @joergm @INNOQ
17. Werden bestimmte Features benötigt? Ja • mTLS • Tracing • Routing • spezielle Rollouts 17 @HannaPrinz @joergm @INNOQ
18. Aktuelle Implementierungen
19. Service Mesh Implementierungen Istio 19 Open Service Mesh @HannaPrinz @joergm @INNOQ
20. 20 @HannaPrinz @joergm @INNOQ
21. Eine Implementierung wählen
22. In welchem Umfeld möchte ich das Service Mesh einsetzen? 22 @HannaPrinz @joergm @INNOQ
23. Fragen zum Umfeld • Welche Infrastruktur habe ich im Einsatz? • Gibt es präferierte Cloudanbieter? • Welches Wissen ist vorhanden? • Wie flexibel wollen wir sein? 23 @HannaPrinz @joergm @INNOQ
24. Kubernetes nur auf Kubernetes auch ohne Kubernetes Istio Open Service Mesh 24 @HannaPrinz @joergm @INNOQ
25. Cloud Anbieter • Der Einfluss ist gering, so lange Kubernetes zum Einsatz kommt • Viele AWS Services (insbesondere Fargate/ECS) können ein Indikator für AWS App Mesh sein • Google Cloud hat sehr guten Istio Support • Microsoft Azure wird sich vermutlich in Richtung OSM bewegen 25 @HannaPrinz @joergm @INNOQ
26. Unabhängigkeit durch SMI? • "A standard interface for service meshes on Kubernetes“ • Features: • Traffic Access Control • Traffic Metrics • Traffic Specs • Traffic Split • Definiert CRDs in Kubernetes, auf die die Implementierungen zugreifen 26 @HannaPrinz @joergm @INNOQ
27. Service Mesh Interface Support voll ohne Istio Open Service Mesh teilweise 27 @HannaPrinz @joergm @INNOQ
28. Welche Features werden benötigt? 28 @HannaPrinz @joergm @INNOQ
29. Fragen zu Features • Welche Probleme gibt es aktuell im Projekt? • Gibt es Must-Haves/Nice-to-Haves? • Welches Level an Konfigurierbarkeit ist nötig? • Welcher Aufwand soll betrieben werden? 29 @HannaPrinz @joergm @INNOQ
30. Unterschiede zwischen den Meshes Observability Resilience Routing Security 30 @HannaPrinz @joergm @INNOQ
31. Proxy & Ingress 31 @HannaPrinz @joergm @INNOQ Istio Proxy pro Service & als Ingress Gateway Proxy pro Service Proxy pro Node Andere Service Meshes
32. Canary Releasing & A/B Testing Service A Header: city=* Header: city=berlin Service B Istio Open Service Mesh 32 Canary @HannaPrinz @joergm @INNOQ Service A Canary Service B Rein prozentual + Header- oder Pfad-basiert 90% 10% / /neu
33. Unterschiede zwischen den Meshes Observability Resilience Routing Security 33 @HannaPrinz @joergm @INNOQ
34. Resilience Unterschiede • Nicht von allen Service Meshes unterstützt • Retry-Config gilt teilweise pro Service → keine Ausnahme von nicht-idempotenten Endpunkten wie HTTP POST! 34 Timeout Retry Service 1 Service 2 Proxy Proxy 4s Circuit Breaking @HannaPrinz @joergm @INNOQ
35. Chaos Engineering • In Istio, Kuma und teilw. Linkerd unterstützt • Umsetzung teilweise über zusätzliches Deployment + SMI Traffic Split 35 Fault Injection Delay Injection Service 1 Service 2 Proxy Proxy @HannaPrinz @joergm @INNOQ
36. Fault Injection durch Traffic Split Normaler Service Fehlerproduzent 99% 1% 36 @HannaPrinz @joergm @INNOQ → Z.B. bei Linkerd 2 → Benötigt zusätzliches Deployment, das Fehler produziert
37. Unterschiede zwischen den Meshes Observability Resilience Routing Security @HannaPrinz @joergm @INNOQ 37
38. Security Unterschiede • Alle Meshes bis auf Traefik Mesh unterstützen mTLS • Unterschiede gibt es • bei mTLS für TCP-Verbindungen • beim Erzwingen von mTLS (TLS Enforcement) Service 1 Service 2 Proxy Proxy "Service 1" mTLS @HannaPrinz @joergm @INNOQ 38
39. Unterschiede zwischen den Meshes Observability Resilience Routing Security 39 @HannaPrinz @joergm @INNOQ
40. Observability Unterschiede • Qualität des Dashboards 40 @HannaPrinz @joergm @INNOQ
41. @HannaPrinz @joergm @INNOQ
42. @HannaPrinz @joergm @INNOQ
43. Observability Unterschiede • Qualität des Dashboards • Vorkonfiguriertes Prometheus, Grafana und Jaeger • Tracing-Support • Access Logs • Alternative von Linkerd: Echtzeit-Logs mit "tap" 43 @HannaPrinz @joergm @INNOQ
44. @HannaPrinz @joergm @INNOQ
45. Passt das Service Mesh subjektiv (Produktionsreife, Usability …)? 45 @HannaPrinz @joergm @INNOQ
46. Produktionsreife Spitzengruppe Sehr Neu Istio Open Service Mesh Verfolgerfeld 46 @HannaPrinz @joergm @INNOQ
47. Komplexität der Konfiguration 47 Newsservice A Newsservice B Beispiel Traffic Split 90% 10% @HannaPrinz @joergm @INNOQ
48. Traffic Split Istio apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: newsservice-istio spec: host: newsservice subsets: - name: A labels: version: "A" - name: B labels: version: "B" apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: newsservice-istio spec: hosts: - newsservice http: - route: - destination: host: newsservice subset: A weight: 90 - destination: host: newsservice subset: B weight: 10 48 @HannaPrinz @joergm @INNOQ
49. Traffic Split SMI apiVersion: split.smi-spec.io/v1alpha1 kind: TrafficSplit metadata: name: newsservice-smi spec: service: newsservice backends: - service: newsservice-a weight: 90 - service: newsservice-b weight: 10 49 @HannaPrinz @joergm @INNOQ
50. Komplexes Debugging Service 1 Service 2 Proxy Proxy Ingress Control Plane Kubernetes + Overlay Network Hardware oder Cloudumgebung 50 @HannaPrinz @joergm @INNOQ
51. Performance & Benchmarking --> https://github.com/kinvolk/service-mesh-benchmark @HannaPrinz @joergm @INNOQ • Zusätzliche Latenz: ca. 3ms • Zusätzliche CPU & Memory- Ressourcen • Abhängig von Architektur, Traffic und Service Mesh → Eigener Benchmark! 51
52. Fazit
53. Schritte zum Service Mesh 0. Ist ein Service Mesh der sinnvolle nächste Schritt? → liegt das Problem woanders? 1. Was ist die technische Umgebung? → Kubernetes/Cloud/Infrastruktur-Tools 2. Welche Features werden benötigt? → Must-Haves/Nice-to-Haves? 3. Passt das Service Mesh subjektiv? → Produktionsreife, Developer Experience, Config, Performance 53 @HannaPrinz @joergm @INNOQ
54. Mehr zum Thema • Service Mesh Vergleich auf servicemesh.es • Gut gesiebt: Service Meshes im Vergleich https://www.innoq.com/de/articles/2020/10/service-meshes-im-vergleich/ • Artikel: Glücklich ohne Service Mesh https://www.innoq.com/de/blog/gluecklich-ohne-service-mesh/ • Podcast zu Service Meshes https://www.innoq.com/de/podcast/059-service-meshes-1/ • Beispiel-Anwendung auf GitHub https://github.com/ewolff/microservice-istio • Tutorial von Linkerd https://linkerd.io/2/tasks/ • Tutorial von Istio https://istio.io/docs/setup/getting-started/ • Artikel: Alle 11 Minuten verliebt sich ein Microservice in Linkerd https://www.innoq.com/en/articles/2020/01/linkerd2/ • Beispiel-Anwendung mit Istio und Linkerd Tutorial on GitHub https://github.com/ewolff/microservice-istio https://github.com/ewolff/microservice-linkerd @INNOQ @JoergM @HannaPrinz GOTO 2020 • Getting started with Service Mesh https://www.youtube.com/watch?v=w14ge2838Vs Technology Lunch 2020 • Service Mesh https://www.youtube.com/watch?v=cTfp7It1eEo
55. innoQ Deutschland GmbH innoQ Schweiz GmbH www.innoq.com Danke! Fragen? Hanna Prinz hanna.prinz@innoq.com @HannaPrinz Jörg Müller joerg.mueller@innoq.com @joergm Icons made by srip, Smashicons, Nikita Golubev, Freepik, surang and Darius Dan from www.flaticon.com and licensed by CC 3.0 BY Service Mesh Primer - 2nd Edition Auf leanpub.com/service-mesh-primer Krischerstr. 100 40789 Monheim am Rhein Germany +49 2173 3366-0 Ohlauer Str. 43 10999 Berlin Germany +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany +49 2173 3366-0 Kreuzstr. 16 80331 München Germany +49 2173 3366-0 Hermannstrasse 13 20095 Hamburg Germany +49 2173 3366-0 Gewerbestr. 11 CH-6330 Cham Switzerland +41 41 743 0116