Slide 1

Slide 1 text

Service Mesh - Was die neue Infrastruktur für Microservices taugt Hanna Prinz 3 0 . 0 1 . 2 0 2 0 D e v O p s K a r l s r u h e

Slide 2

Slide 2 text

@HannaPrinz Warum Service Meshes?

Slide 3

Slide 3 text

@HannaPrinz Monolith Microservices

Slide 4

Slide 4 text

@HannaPrinz Microservices

Slide 5

Slide 5 text

@HannaPrinz Timeout Circuit Breaking Verschlüsselung Retry Metriken erzeugen & bereitstellen Entschlüsselung Autorisierung prüfen Routing

Slide 6

Slide 6 text

@HannaPrinz Service Mesh Metriken Konfiguration Retry Timeout Circuit Breaker Routing Verschlüsseln Entschlüsseln Autorisierung Metriken ... } @HannaPrinz

Slide 7

Slide 7 text

@HannaPrinz Microservices mit Service Mesh Service Mesh Evolution Monolith Microservices Theorie Microservices Praxis

Slide 8

Slide 8 text

@HannaPrinz Infrastruktur-Service Y Service Mesh Architektur Microservice 1 Microservice 2 Proxy Proxy Control Plane App Infrastruktur-Service X Anwendung Data Plane Control Plane Infrastruktur

Slide 9

Slide 9 text

@HannaPrinz Was kann ein Service Mesh?

Slide 10

Slide 10 text

@HannaPrinz Service Mesh Features Observability Resilience Routing Security Beispiele mit dem Istio Service Mesh

Slide 11

Slide 11 text

@HannaPrinz Monitoring Ein Service Mesh kann automatisch Daten für alle 4 "Golden Signals" liefern: Latenz Requests/Sekunde Status Codes (Fehler) Auslastung ... es hat aber keinen Einblick in die Microservices https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/#xref_monitoring_golden-signals

Slide 12

Slide 12 text

@HannaPrinz Monitoring mit Service Mesh Microservice 1 Microservice 2 Proxy Proxy Control Plane App Dashboard Monitoring-System Anwendung Data Plane Control Plane Infrastruktur 12

Slide 13

Slide 13 text

@HannaPrinz Monitoring mit Service Mesh Metriken zum Netzwerkverkehr generieren -> Latenz / Antwortzeit -> HTTP Status Codes -> Anfragen pro Sekunde Metriken an ein Monitoring- System senden Metriken mit Dashboards aufbereiten 13

Slide 14

Slide 14 text

@HannaPrinz Monitoring mit Istio

Slide 15

Slide 15 text

@HannaPrinz Monitoring mit Istio basiert auf... Prometheus Grafana 15 Kiali Jaeger

Slide 16

Slide 16 text

@HannaPrinz Monitoring mit Istio Microservice 1 Microservice 2 Envoy Proxy Envoy Proxy Anwendung Data Plane Control Plane Mixer Infrastruktur Grafana Prometheus 16 Kiali

Slide 17

Slide 17 text

@HannaPrinz 17 •Fachlich: •Online-Shop für Hipsterbedarf •Technologisch: •10 Microservices mit verschiedenen Technologien •Aufruf einer externen API für Währungsumrechnungen •Redis für Warenkorb •Kommunikation über gRPC Beispielanwendung: Hipstershop

Slide 18

Slide 18 text

User Frontend Go AdService Java CheckoutService Go CurrencyService Node.js CartService C# EmailService Python RecommendationServ. Python ProductCatalogServ. Go PaymentService Node.js ShippingService Go Redis Cache Load Generator Python EZB API Hipstershop Services @HannaPrinz

Slide 19

Slide 19 text

@HannaPrinz Demo

Slide 20

Slide 20 text

@HannaPrinz @HannaPrinz

Slide 21

Slide 21 text

@HannaPrinz Tracing •Beantwortet... •Welcher Aufruf erzeugt welchen Folgeaufruf? •Welchen Anteil hat jeder Teilaufruf an der Latenz? •Wo ist ein Fehler entstanden? •Umsetzung: Tracing- Backend B C A 3s Latenz #42 #42 #42 Trace von Aufruf #42 A B C 21

Slide 22

Slide 22 text

@HannaPrinz Tracing mit Service Mesh | Config Microservice 1 Microservice 2 Proxy Proxy Tracing-Backend Anwendung Data Plane Control Plane Infrastruktur 22

Slide 23

Slide 23 text

@HannaPrinz Tracing mit Service Mesh Tracing-Header an ausgehende Anfragen kopieren Tracing-Daten an ein Tracing-Backend senden Tracing-Daten in Dashboard aufbereiten 23

Slide 24

Slide 24 text

@HannaPrinz Demo

Slide 25

Slide 25 text

@HannaPrinz @HannaPrinz

Slide 26

Slide 26 text

@HannaPrinz Service Mesh Features Observability Resilience Routing Security

Slide 27

Slide 27 text

@HannaPrinz Routing Typischerweise im Edge Router / API- Gateway implementiert z.B. NGINX, Kong, Ambassador, Traefik Instance A Instance B Load Balancing Instance A Instance B Pfad-basiertes Routing /a /b Instance A Instance B Blue/Green Deployment Instance A Instance B A/B-Testing 50% 50% Instance A Instance B Canary Releasing Berlin Welt 27

Slide 28

Slide 28 text

@HannaPrinz Routing mit Service Mesh | Config Microservice 1 Microservice 2 Proxy Proxy Control Plane App Anwendung Data Plane Control Plane Routing- Regeln 28

Slide 29

Slide 29 text

@HannaPrinz Routing mit Service Mesh GET /neu GET / 90% 10% Service 1 Service 2A Proxy Proxy Service 2B Proxy Komplexe Routing-Regeln für A/B Testing und Canary Releasing Service 1 Service 2 Proxy Proxy Service 2 Proxy PRODUKTION STAGING Traffic Mirroring locality=mars locality=* 29

Slide 30

Slide 30 text

@HannaPrinz Routing mit Istio

Slide 31

Slide 31 text

@HannaPrinz Beispiel-Routing mit Istio GET /neu GET / Frontend v1 Ingress Proxy Proxy Frontend v2 Proxy 31

Slide 32

Slide 32 text

@HannaPrinz 32 Routing Config apiVersion: networking.istio.io/… kind: DestinationRule metadata: name: frontend apiVersion: networking.istio.io/… kind: VirtualService metadata: name: frontend-ingress spec: hosts: - "*" Regel 1: Wenn die URI "/neu" enthält, dann leite an frontend v2 weiter Regel 2: Ansonsten leite an frontend v1 weiter http: - match: - uri: prefix: "/neu" route: - destination: host: frontend subset: v2 - route: - destination: host: frontend subset: v1 Subset “v2”: Alle Pods mit Label version: "2" Subset “v1”: Alle Pods mit Label version: "1" spec: host: frontend subsets: - name: v2 labels: version: "2" - name: v1 labels: version: "1" @HannaPrinz

Slide 33

Slide 33 text

@HannaPrinz Demo

Slide 34

Slide 34 text

@HannaPrinz @HannaPrinz

Slide 35

Slide 35 text

@HannaPrinz Service Mesh Features Observability Resilience Routing Security

Slide 36

Slide 36 text

@HannaPrinz Resilience Was wenn ein Service nicht wie erwartet zur Verfügung steht? Ziel: Gesamtsystem funktioniert weiter ... ggf. mit Einschränkungen Maßnahmen: Retry, Timeout, Circuit Breaking 36 500

Slide 37

Slide 37 text

@HannaPrinz Resilience mit Service Mesh | Config Microservice 1 Microservice 2 Proxy Proxy Control Plane App Anwendung Data Plane Control Plane Resilienz- Regeln 37

Slide 38

Slide 38 text

@HannaPrinz Resilience mit Service Mesh Fault Injection Delay Injection Service 1 Service 2 Proxy Proxy Timeout Retry Service 1 Service 2 Proxy Proxy 4s 502 38

Slide 39

Slide 39 text

@HannaPrinz Resilience mit Istio Retry & Timeout

Slide 40

Slide 40 text

@HannaPrinz Timeout & Retry hosts: Zieladresse des Client-Requests destination: Wo der Request tatsächlich hingeht max. Anzahl der Retrys Timeout pro Retry Bedingungen für ein Retry Timeout für alle Retrys zusammen apiVersion: networking.istio.io/... kind: VirtualService metadata: name: recommendationservice spec: hosts: - recommendationservice route: - destination: host: recommendationservice http: - retries: attempts: 3 perTryTimeout: 1s retryOn: connect-failure,5xx timeout: 2s @HannaPrinz

Slide 41

Slide 41 text

@HannaPrinz Service Mesh Features Observability Resilience Routing Security

Slide 42

Slide 42 text

@HannaPrinz Security mit Service Mesh | Config Microservice 1 Microservice 2 Proxy Proxy Anwendung Data Plane Control Plane Control Plane App Autorisierungs- Regeln TLS-Zertifikat 42

Slide 43

Slide 43 text

@HannaPrinz Security mit Service Mesh Service 1 Service 2 Proxy Proxy "Service 1" Authentifizierung mit mTLS Autorisierung Service 1 Service 2 Proxy Proxy GET /api GET / Autorisierungs-Regel TLS-Zertifikat 43

Slide 44

Slide 44 text

@HannaPrinz Service Mesh Features Netzwerk-Metriken und -Logs Daten an Tracing-Backend senden Automatische Timeouts & Retrys Automatisches Circuit Breaking Business-Metriken oder -Logs Weitergabe von Tracing-Headern Cache oder Standardantworten in Circuit Breaker nutzen Routing anhand von Request Body Automatisierung Canary Releasing Authentifizierung mit mTLS Autorisierung Komplexe Routing-Regeln Canary Releasing & A/B-Testing Observability Resilience Routing Security

Slide 45

Slide 45 text

@HannaPrinz One Mesh to rule them all?

Slide 46

Slide 46 text

@HannaPrinz Service Mesh Implementierungen Istio Vergleich auf

Slide 47

Slide 47 text

@HannaPrinz 47

Slide 48

Slide 48 text

Was ist wichtig für die Auswahl eines Service Mesh? Features Kompatibilität Performance Usability

Slide 49

Slide 49 text

@HannaPrinz Istio VS Linkerd 2 *2017 von Google & IBM optimiert auf Featureanzahl und Konfigurierbarkeit optimiert für Kubernetes, aber erweiterbar *2017 von Buoyant optimiert auf Usability und Performance Kubernetes only

Slide 50

Slide 50 text

@HannaPrinz 50 Features Istio 1.4 Linkerd 2.6 Generell Plattform Kubernetes+ Kubernetes Automatische Sidecar-Injektion ✓ ✓ Sicherheit Authentifizierung via mTLS ✓ ✓ Autorisierung ✓ ✘ Resilienz Timeouts & Retrys ✓ ✓ Circuit Breaker ✓ ✘ Routing Load Balancing ✓ ✓ Routing-Regeln ✓ ✓ Monitoring Metriken ✓ ✓ Tracing ✓ (✓) Dashboard mit Service Graph ✓ ✓

Slide 51

Slide 51 text

@HannaPrinz 51

Slide 52

Slide 52 text

@HannaPrinz 52 Performance & Ressourcen •Latenz •Istio: zusätzlich ca. 6,3ms Latenz - pro Aufruf zwischen Services! •Linkerd 2: ähnlich, mit weniger starken Schwankungen •Ressourcen •Zusätzliche Container für Control Plane & jedes Sidecar •→ Erhöhter CPU- & Arbeitsspeicher-Verbrauch Aber: Abhängig von konkretem Setting → eigenen Benchmark machen!

Slide 53

Slide 53 text

@HannaPrinz 53 Usability

Slide 54

Slide 54 text

@HannaPrinz Service Mesh Fazit Löst viele wesentliche Probleme von Microservices + Eine weitere komplexe Technologie – ... ohne Codeänderungen! Latenz- und Ressourcen- Overhead 54 @HannaPrinz

Slide 55

Slide 55 text

@HannaPrinz 55 Entscheidungshilfe Mesh oder kein Mesh? Istio oder Linkerd 2? •Service Mesh wenn: •Großteil in Kubernetes läuft •Viele Microservices, viele synchrone Aufrufe •Viele ungelöste Probleme beim Monitoring, Routing, Resilienz und/oder Security •Istio nur wenn Komplexität und Flexibilität nötig ist: •Teilsystem bleibt außerhalb von Kubernetes •Circuit Breaking und Autorisierung unverzichtbar •Ausreichend zeitliche und kognitive Kapazität im Team @HannaPrinz

Slide 56

Slide 56 text

@HannaPrinz Mehr Mesh • Artikel Brauchen asynchrone Microservices und Self-Contained-Systems ein Service Mesh? • Artikel Alle 11 Minuten verliebt sich ein Microservice in Linkerd • Service Mesh Vergleich auf servicemesh.es • Podcast zu Service Meshes • Beispiel-Anwendung auf GitHub • Tutorial von Linkerd • Tutorial von Istio

Slide 57

Slide 57 text

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 innoQ Deutschland GmbH innoQ Schweiz GmbH www.innoq.com Danke! Fragen? Hanna Prinz [email protected] @HannaPrinz Icons made by srip, Smashicons, Nikita Golubev, Freepik, surang and Darius Dan from www.flaticon.com and licensed by CC 3.0 BY Kostenloser Service Mesh Primer Auf leanpub.com/service-mesh-primer