Slide 1

Slide 1 text

Istio, Linkerd und Co. im Vergleich Welches Service Mesh passt zu mir? Jörg Müller @joergm Hanna Prinz @HannaPrinz

Slide 2

Slide 2 text

Hanna Prinz Consultant innoQ Deutschland GmbH [email protected] @HannaPrinz - Software Development - DevOps, Kubernetes, Service Mesh

Slide 3

Slide 3 text

Jörg Müller Principal Consultant innoQ Deutschland GmbH [email protected] @joergm - architecture, development, DevOps - focus on platform & infrastructure

Slide 4

Slide 4 text

Was ist ein Service Mesh?

Slide 5

Slide 5 text

Microservices sind verteilte Systeme Microservice Timeout Retry Routing und Discovery Verschlüsselung Microservice Authentifizierung / Autorisierung Circuit Breaker Metriken Logs 5 @HannaPrinz @joergm @INNOQ

Slide 6

Slide 6 text

Libraries können helfen Microservice Microservice Lib Lib 6 @HannaPrinz @joergm @INNOQ

Slide 7

Slide 7 text

Kubernetes Pod Pod Kubernetes hilft auch Microservice Microservice Service 7 @HannaPrinz @joergm @INNOQ

Slide 8

Slide 8 text

Service Mesh Ansatz Microservice Proxy Microservice Proxy Control Plane Metriken Konfiguration 8 @HannaPrinz @joergm @INNOQ

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Ist ein Service Mesh überhaupt sinnvoll?

Slide 11

Slide 11 text

Oft lautet die Antwort: Nein

Slide 12

Slide 12 text

Wie viele Services? wenige viele(>~10) nur wenn bestimmte Features anders schwer zu realisieren sind (siehe weiter unten) 12 @HannaPrinz @joergm @INNOQ

Slide 13

Slide 13 text

Vielfalt der Technologien? niedrig Hoch Libraries können ein gute Alternative sein 13 @HannaPrinz @joergm @INNOQ

Slide 14

Slide 14 text

Überwiegend synchrone Kommunikation? Nein Ja Wahrscheinlich bringt ein Service Mesh wenig Mehrwert 14 @HannaPrinz @joergm @INNOQ

Slide 15

Slide 15 text

Ist Kubernetes im Einsatz? Nein Ja Die Auswahl der Lösungen wird erheblich eingeschränkt 15 @HannaPrinz @joergm @INNOQ

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Werden bestimmte Features benötigt? Ja • mTLS • Tracing • Routing • spezielle Rollouts 17 @HannaPrinz @joergm @INNOQ

Slide 18

Slide 18 text

Aktuelle Implementierungen

Slide 19

Slide 19 text

Service Mesh Implementierungen Istio 19 Open Service Mesh @HannaPrinz @joergm @INNOQ

Slide 20

Slide 20 text

20 @HannaPrinz @joergm @INNOQ

Slide 21

Slide 21 text

Eine Implementierung wählen

Slide 22

Slide 22 text

In welchem Umfeld möchte ich das Service Mesh einsetzen? 22 @HannaPrinz @joergm @INNOQ

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Kubernetes nur auf Kubernetes auch ohne Kubernetes Istio Open Service Mesh 24 @HannaPrinz @joergm @INNOQ

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Service Mesh Interface Support voll ohne Istio Open Service Mesh teilweise 27 @HannaPrinz @joergm @INNOQ

Slide 28

Slide 28 text

Welche Features werden benötigt? 28 @HannaPrinz @joergm @INNOQ

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Unterschiede zwischen den Meshes Observability Resilience Routing Security 30 @HannaPrinz @joergm @INNOQ

Slide 31

Slide 31 text

Proxy & Ingress 31 @HannaPrinz @joergm @INNOQ Istio Proxy pro Service & als Ingress Gateway Proxy pro Service Proxy pro Node Andere Service Meshes

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Unterschiede zwischen den Meshes Observability Resilience Routing Security 33 @HannaPrinz @joergm @INNOQ

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Unterschiede zwischen den Meshes Observability Resilience Routing Security @HannaPrinz @joergm @INNOQ 37

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Unterschiede zwischen den Meshes Observability Resilience Routing Security 39 @HannaPrinz @joergm @INNOQ

Slide 40

Slide 40 text

Observability Unterschiede • Qualität des Dashboards 40 @HannaPrinz @joergm @INNOQ

Slide 41

Slide 41 text

@HannaPrinz @joergm @INNOQ

Slide 42

Slide 42 text

@HannaPrinz @joergm @INNOQ

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

@HannaPrinz @joergm @INNOQ

Slide 45

Slide 45 text

Passt das Service Mesh subjektiv (Produktionsreife, Usability …)? 45 @HannaPrinz @joergm @INNOQ

Slide 46

Slide 46 text

Produktionsreife Spitzengruppe Sehr Neu Istio Open Service Mesh Verfolgerfeld 46 @HannaPrinz @joergm @INNOQ

Slide 47

Slide 47 text

Komplexität der Konfiguration 47 Newsservice A Newsservice B Beispiel Traffic Split 90% 10% @HannaPrinz @joergm @INNOQ

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

Komplexes Debugging Service 1 Service 2 Proxy Proxy Ingress Control Plane Kubernetes + Overlay Network Hardware oder Cloudumgebung 50 @HannaPrinz @joergm @INNOQ

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Fazit

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

innoQ Deutschland GmbH innoQ Schweiz GmbH www.innoq.com Danke! Fragen? Hanna Prinz [email protected] @HannaPrinz Jörg Müller [email protected] @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