Service Mesh - was die neue Infrastruktur für Microservices taugt

Mal ganz ehrlich: Manchmal wünschen wir uns doch den guten alten Monolithen zurück. Lückenlose Nachvollziehbarkeit von Fehlern, kein Prometheus- und Grafana-Gebastel, keine Vorkehrungen für allerlei Netzwerkprobleme und nur ein Endpunkt, den es abzusichern gilt. Freie Bahn, um Features zu entwickeln. Die Funktionen, die wir rund um unsere Microservices „nebenbei“ implementieren, haben ein wenig Überhand genommen. Genau das verspricht ein Service Mesh zu ändern. Es hebt Monitoring, Resilienz, Routing und Sicherheit in die Infrastruktur. Wir müssen reden – über sinnvolle Anwendungsfälle für Service Mesh Technologien wie Istio und Linkerd 2 und über den Preis: Ressourcenverbrauch und Performance.

Transcript

1. Service Mesh was die neue Infrastruktur für Microservices taugt 1 6 . 0 7. 2 0 2 0 J U G D a r m s t a d t 1 Hanna Prinz
2. ~ "Fix your Microservices by throwing a Mesh at it!" ~
3. @INNOQ @HannaPrinz Wie ist es so weit gekommen?
4. Monolith Microservices @INNOQ @HannaPrinz
5. Microservices @INNOQ @HannaPrinz
6. Timeout Circuit Breaking Verschlüsselung Retry Metriken sammeln & bereitstellen Entschlüsselung Autorisierung Routing @INNOQ @HannaPrinz
7. Service Mesh Metriken Konfiguration Retry Timeout Circuit Breaker Routing Verschlüsseln Entschlüsseln Autorisierung Metriken ... } @INNOQ @HannaPrinz
8. Microservices mit Service Mesh Service Mesh Evolution Monolith Microservices Theorie Microservices Praxis @INNOQ @HannaPrinz
9. Infrastruktur-Service Y Service Mesh Architecture Microservice 1 Microservice 2 Proxy Proxy Control Plane App Infrastruktur-Service X Anwendung Data Plane Control Plane Infrastruktur @INNOQ @HannaPrinz
10. Hurra, Technologie! @INNOQ @HannaPrinz
11. Service Mesh Features Observability Resilience Routing Security @INNOQ @HannaPrinz
12. Monitoring Ein Service Mesh kann automatisch 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 @INNOQ @HannaPrinz
13. Monitoring mit Service Mesh Metriken zum Netzwerkverkehr generieren -> Latenz / Antwortzeit -> HTTP Status Codes -> Anfragen pro Sekunde ... einem Monitoring-System zur Verfügung stellen ... und mit Dashboards aufbereiten @INNOQ @HannaPrinz
14. Order Shipping Invoicing Postgres Beispiel-Anwendung Service nutzen weder Code noch Bibliotheken für Monitoring https://github.com/ewolff/microservice-istio
15. @INNOQ @HannaPrinz Istio
16. Service Mesh Features Observability Resilience Routing Security @INNOQ @HannaPrinz
17. Routing Typischerweise im Edge Router / API-Gateway implementiert z.B. NGINX, Envoy, 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 17 @INNOQ @HannaPrinz
18. Routing mit Service Mesh Microservice 1 Microservice 2 Proxy Proxy Control Plane App Anwendung Data Plane Control Plane Routing- Regeln 18 @INNOQ @HannaPrinz
19. 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=* 19 @INNOQ @HannaPrinz
20. Service Mesh Features Observability Resilience Routing Security @INNOQ @HannaPrinz
21. 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 21 500 @INNOQ @HannaPrinz
22. Resilience mit Service Mesh Microservice 1 Microservice 2 Proxy Proxy Control Plane App Anwendung Data Plane Control Plane Resilienz- Regeln 22 @INNOQ @HannaPrinz
23. Resilience mit Service Mesh Fault Injection Delay Injection Service 1 Service 2 Proxy Proxy Timeout Retry Service 1 Service 2 Proxy Proxy 4s 502 23 @INNOQ @HannaPrinz
24. Service Mesh Features Observability Resilience Routing Security @INNOQ @HannaPrinz
25. Security mit Service Mesh Microservice 1 Microservice 2 Proxy Proxy Anwendung Data Plane Control Plane Control Plane App Autorisierungs- Regeln TLS-Zertifikat 25 @INNOQ @HannaPrinz
26. Security mit Service Mesh Service 1 Service 2 Proxy Proxy Authentifizierung mit mTLS Autorisierung Service 1 Service 2 Proxy Proxy GET /api GET / Autorisierungs-Regel TLS-Zertifikat 26 @INNOQ @HannaPrinz "Service 1"
27. Service Mesh Features Netzwerk-Metriken und Access Logs Tracing-Daten an Backend senden Timeouts & Retrys Circuit Breaking Business-Metriken oder -Logs Weitergabe von Tracing-Headern Alerting Cache oder Standardantworten in Circuit Breaker nutzen Automatisches Canary Releasing Authentifizierung mit mTLS Autorisierung Komplexe Routing-Regeln Canary Releasing & A/B-Testing Observability Resilience Routing Security @INNOQ @HannaPrinz
28. Service Mesh Markt @INNOQ @HannaPrinz
29. Service Mesh Implementierungen Istio @INNOQ @HannaPrinz
30. 30 @INNOQ @HannaPrinz
31. Istio VS Linkerd 2 *2017 von Google & IBM optimiert auf Featureanzahl und Konfigurierbarkeit optimiert für Kubernetes, aber nicht exklusiv *2017 von Buoyant optimiert auf Usability und Performance Kubernetes only @INNOQ @HannaPrinz
32. Features @INNOQ @HannaPrinz Netzwerk-Metriken und Access Logs Tracing-Daten an Backend senden Timeouts & Retrys Circuit Breaking Authentifizierung mit mTLS Autorisierung Komplexe Routing-Regeln Canary Releasing & A/B-Testing Observability Resilience Routing Security Istio ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✗
33. Schöne Tabelle. @INNOQ @HannaPrinz
34. 34 Usability @INNOQ @HannaPrinz
35. apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: istio-attributegen-filter spec: workloadSelector: labels: app: reviews configPatches: - applyTo: HTTP_FILTER match: context: SIDECAR_INBOUND proxy: proxyVersion: '1\.6.*' listener: filterChain: filter: name: "envoy.http_connection_manager" subFilter: name: "istio.stats" patch: operation: INSERT_BEFORE value: name: istio.attributegen typed_config: "@type": type.googleapis.com/udpa.type.v1.TypedStruct type_url: type.googleapis.com/envoy.extensions.filters. value: config: configuration: | { "attributes": [ { "output_attribute": "istio_operationId", "match": [ { "value": "GET /users", "condition": "request.url_path == '/use }, { "value": "POST /order", "condition": "request.url_path == '/ord }, { "value": "GET /invoice/{id}", "condition": "request.url_path.matches( && request.method == 'GET'" } ] } ] } vm_config: runtime: envoy.wasm.runtime.null code: local: { inline_string: "envoy.wasm.attributege Service Mesh Magie basiert auf einer Menge YAML apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: istio-attributegen-filter spec: workloadSelector: labels: app: reviews configPatches: - applyTo: HTTP_FILTER match: context: SIDECAR_INBOUND proxy: proxyVersion: '1\.6.*' listener: filterChain: filter: name: "envoy.http_connection_manager" subFilter: name: "istio.stats" patch: operation: INSERT_BEFORE value: name: istio.attributegen typed_config: "@type": type.googleapis.com/udpa.type.v1.TypedStruct type_url: type.googleapis.com/envoy.extensions.filters.h value: config: configuration: | { "attributes": [ { "output_attribute": "istio_operationId", "match": [ { "value": "GET /users", "condition": "request.url_path == '/user }, { "value": "POST /order", "condition": "request.url_path == '/orde }, { "value": "GET /invoice/{id}", "condition": "request.url_path.matches(' && request.method == 'GET'" } ] } ] } vm_config: runtime: envoy.wasm.runtime.null code: local: { inline_string: "envoy.wasm.attributegen
36. @INNOQ @HannaPrinz Istio VS Linkerd 2 Konfiguration im Vergleich
37. Service 11ms GET /users POST /order GET /invoice/42 Service 4ms 17ms 2ms Auflösung der Metriken... @INNOQ @HannaPrinz ... pro Service ... pro Endpunkt
38. @INNOQ @HannaPrinz
39. Metriken pro Endpunkt mit apiVersion: linkerd.io/v1alpha1 kind: ServiceProfile metadata: name: service-b.default.svc.cluster.local namespace: default spec: routes: - name: GET /users condition: method: GET pathRegex: /users - name: POST /order condition: method: POST pathRegex: /order - name: GET /invoice/{id} condition: method: GET pathRegex: /invoice/[^/]* Service A GET /users POST /order GET /invoice/42 Service B 4ms 17ms 2ms @INNOQ @HannaPrinz Linkerd 2
40. Metriken pro Endpunkt mit apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: istio-attributegen-filter spec: workloadSelector: labels: app: reviews configPatches: - applyTo: HTTP_FILTER match: context: SIDECAR_INBOUND proxy: proxyVersion: '1\.6.*' listener: filterChain: filter: name: "envoy.http_connection_manager" subFilter: name: "istio.stats" patch: operation: INSERT_BEFORE value: name: istio.attributegen typed_config: "@type": type.googleapis.com/udpa.type.v1.TypedStruct type_url: type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm value: config: configuration: | { "attributes": [ { "output_attribute": "istio_operationId", "match": [ { "value": "GET /users", "condition": "request.url_path == '/users' && request.method == 'GET'" }, { "value": "POST /order", "condition": "request.url_path == '/order' && request.method == 'POST'" }, { "value": "GET /invoice/{id}", "condition": "request.url_path.matches('^/invoice/[[:alnum:]]*$') && request.method == 'GET'" } ] } ] } vm_config: runtime: envoy.wasm.runtime.null code: local: { inline_string: "envoy.wasm.attributegen" } Service A GET /users POST /order GET /invoice/42 Service B 4ms 17ms 2ms @INNOQ @HannaPrinz Istio Experimentell in Version 1.6
41. 41 Performance & Ressourcen •Latenz - stark abhängig vom Traffic •Istio: zusätzlich ca. 3ms Latenz - pro Aufruf zwischen Services! •Linkerd 2: keine aktuellen Zahlen, in früheren Versionen ähnlich •Ressourcen •Zusätzliche Container für Control Plane & jedes Sidecar •→ Erhöhter CPU- & Arbeitsspeicher-Verbrauch Aber: Abhängig von konkretem Setting → eigenen Benchmark machen! @INNOQ @HannaPrinz
42. TL;DR @INNOQ @HannaPrinz
43. Service Mesh Löst viele wesentliche Probleme von Microservices + Eine weitere komplexe Technologie – ... ohne Codeänderungen! Latenz- und Ressourcen- Overhead 43 @INNOQ @HannaPrinz
44. Entscheidungshilfe Service Mesh Indikatoren Kriterien für die Auswahl • Viele Microservices, viele synchrone Aufrufe • Viele ungelöste Probleme beim Monitoring, Routing, Resilienz und/oder Security • Großteil läuft in Kubernetes • Welche Features fehlen wirklich? • Vorhandene Infrastruktur - Kubernetes, Consul, AWS, ... • Zeitliche und kognitive Kapazität im Team • Aktivität der Community @INNOQ @HannaPrinz Ziel: So viel Komplexität wie nötig, aber so wenig wie möglich
45. Komplexität? Öhm... @INNOQ @HannaPrinz
46. Monolith Microservices @INNOQ @HannaPrinz
47. "don't distribute your objects." ☝ https://martinfowler.com/articles/distributed-objects-microservices.html Martin Fowler @INNOQ @HannaPrinz
48. Alternativen? @INNOQ @HannaPrinz https://www.infoq.com/articles/architecture-trends-2020/
49. Try not to need a Service Mesh
50. Mehr zum Thema • Service Mesh Vergleich auf servicemesh.es https://servicemesh.es/ • Artikel: Glücklich ohne Service Mesh https://www.innoq.com/de/blog/gluecklich-ohne-service-mesh/ • Artikel: Brauchen asynchrone Microservices und Self-Contained-Systems ein Service Mesh? https://www.innoq.com/de/articles/2020/02/service-mesh-asynchrone-microservices-scs/ • Artikel: Alle 11 Minuten verliebt sich ein Microservice in Linkerd https://www.innoq.com/en/articles/2020/01/linkerd2/ • 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/ @INNOQ @HannaPrinz
51. 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 hanna.prinz@innoq.com @HannaPrinz 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 Kostenlos auf leanpub.com/service-mesh-primer