Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Service Mesh - Kilometer 30 im Microservices-Marathon

84 vues

Publié le

Verteile Anwendungen wie Microservices verlagern einen Teil der Komplexität in das Zusammenspiel der Services untereinander. Ein solches Service Mesh, das bis zu dreistellige (oder mehr) Laufzeitinstanzen haben kann, wird sehr schwierig zu beherrschen. Man muss sich mit Fragen auseinander setzen wie zum Beispiel: Welcher Service wird von welchem Service in welcher Version bei welchem Request-Inhalt wie oft aufgerufen? Wie kann man das Zusammenspiel testen und wie werden einzelne Services durch neue ersetzt?

Diese und andere Fragestellungen werden in der Session beleuchtet. Dabei werden auch Werkzeuge vorgestellt, die das Leben mit dem Service Mesh vereinfachen sollen.

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Service Mesh - Kilometer 30 im Microservices-Marathon

  1. 1. Service Mesh Kilometer 30 im Microservice Marathon Michael Hofmann Hofmann IT-Consulting info@hofmann-itconsulting.de
  2. 2. beim Marathon: ab km 30 ... ● Fettverbrennung, drastische Ermüdung ● Oft Entscheidung über Marathon-Finish ● Richtiges Training ● Spaghetti Party, Essen und Trinken während Lauf ● Mentale Vorbereitung Was tun dagegen? „Der Mann mit dem Hammer“
  3. 3. km 30 bei Microservices? ● Microservice Projekte starten klein (Greenfield, Zerlegung Monolith) ● Anfangs ohne Versionierungs-Probleme ● Mehrere Versionen parallel in Produktion ● Anzahl der Services steigt ● Service-Ketten werden etabliert ● Wie teste ich das Zusammenspiel versionsübergreifend? ● Schleichender Verlust des Überblicks: wer mit wen in welcher Version?
  4. 4. Schon angekommen? Quelle: https://twitter.com/Werner/status/741673514567143424 (Werner Vogels, CTO Amazon) Quelle: Adrian Cockcroft (Netflix) / Martin Fowler
  5. 5. Was kommt noch bei km 30? ● Komplexität auch zwischen den Services ● Fallacies of Distritubed Systems ● Wer kümmert sich darum? – Container-Systeme? – Resilienz-Frameworks? Anwendung sollte nichts davon wissen! The network is reliable. Latency is zero. Bandwidth is infinite. The network is secure. Topology doesn't change. There is one administrator. Transport cost is zero. The network is homogeneous.
  6. 6. Wohin mit der Resilience? ● Frameworks (Hystrix, Failsafe, MicroProfile Fault Tolerance) ● Probleme: – richtiges Pattern wird erst in Produktion erkannt (neues Deployment!) – Abhängigkeit Bibliothek zur Programmiersprache – Versionsmix der Bibliotheken über alle Services hinweg – Abhängigkeiten zu anderen Frameworks (Service-Call → LoadBalancing → Service Registry) – Service Registry für andere Services verwendbar? Doppelte Service Registry? (hohe Kopplung der Services an Infrastruktur-Komponenen!) – Lernkurve bzgl. vieler Frameworks bei jedem Entwickler-Team ● Alternative: Service Mesh Tool
  7. 7. Service Mesh „The term service mesh is used to describe the network of microservices that make up such application and the interactions between them.“ (istio.io) Ohne Werkzeug lässt sich Service Mesh (Big Ball of Mud) kaum beherrschen! Anforderungen an Werkzeug: ● Verwaltung der Aufrufe auf Layer 7 (Application Layer) ● Resilienz, Routing-, Security- und Telemetrie-Funktionalitäten ● Dezentral u. transparent für Services (implementation-independant)
  8. 8. Service Mesh Functions ● Service Discovery ● Load Balancing ● Resilience ● Dynamic Routing (Blue/Green Deployments, Canary Releasing, Traffic Shadowing) ● Observability (Metrics, Tracing) ● End-to-End Authentication, Access Control ● Rate Limiting
  9. 9. Service Mesh Tool ab wann? ● Hohe Anzahl verschiedener Services ● Aufruf-Tiefe der Services > 1 ● Einheitliche Umsetzung der Resilienz gewünscht ● Contemporary testing strategies: Test in Produktionsumgebung (notwendig?)
  10. 10. Service Mesh womit? Vergleich Istio und Linkerd: https://abhishek-tiwari.com/a-sidecar-for-your-service-mesh/
  11. 11. Istio IBM (Amalgam8) content-based routing (extended) service discovery resilience load balancing Google (Istio) content-based routing rate limiting ACLs telemetry Kubernetes integration Lyft (Envoy) proxy (sidecar)
  12. 12. Istio Architektur Quelle: istio.io Data Plane Control Plane
  13. 13. Envoy Proxy Design Goal: „The network should be transparent to applications. When network and application problems do occur it should be easy to determine the source of the problem.“ ● Als Container gemeinsam mit Service deployed ● „Man-in-the-Middle“ ● Als Sidecar transparent für Service ● Service-Discovery, Load-Balancing, Resilience, Health-Checks, Metrics, Fault Injection ● Kommunikation mit Mixer (Telemetrie) und Pilot (Policies)
  14. 14. Mixer Quelle: istio.io
  15. 15. Pilot Quelle: istio.io
  16. 16. Citadel Quelle: istio.io
  17. 17. Automatic Sidecar Injection Herzstück von Istio: Sidecar (Envoy Proxy) automatisch bereitzustellen ● IPTables Modifikation im Pod ● Health-Checks durch Sidecar zum Service ● Restart Pod wenn einer der beiden Container abstürzt kubectl label namespace my-namespace istio-injection=enabled helm install install/kubernetes/helm/istio --name istio --namespace istio-system
  18. 18. Traffic Management Quelle: istio.io
  19. 19. Traffic Management apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 95 - destination: host: reviews subset: v2 weight: 5 ● 95%: reviews v1 ● 5%: reviews v2 kubectl apply -f reviews-v1-95-v2-5.yaml
  20. 20. Traffic Management apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: x-canary: exact: „v2“ route: - destination: host: reviews subset: v2 - route: - destination: host: reviews subset: v1 Mit HTTP Header: ● x-canary=v2: – reviews v2 ● Ohne Header: – v1 ● Reihenfolge wichtig: -match vor -route
  21. 21. apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews subsets: - name: v1 labels: version: v1 trafficPolicy: connectionPool: http: http1MaxPendingRequests: 2 tcp: maxConnections: 5 outlierDetection: http: baseEjectionTime: 15m consecutiveErrors: 3 interval: 1m Circuit Breaker ● max. 5 Connections auf reviews v1 und max. 2 pending requests ● Alles darüber: HTTP Status Code 503 ● Bei 3 aufeinanderfolgenden Fehlern (5xx) innerhalb 1 min.: upstream-host wird für 15 min. aus Pool entfernt
  22. 22. Retry - Timeout ● Max. 3 Versuche mit jeweils 2s Timeout pro Versuch apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 retries: attempts: 3 perTryTimeout: 2s
  23. 23. Fault Injection apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - fault: delay: fixedDelay: 7s percent: 90 abort: httpStatus: 500 percent: 10 route: - destination: host: reviews subset: v1 - route: - destination: host: reviews subset: v1 ● 90%: 7s delay ● 10%: HTTP Status Code 500
  24. 24. Traffic Shadowing ● Zweck: paralleler Test der neuen Version v2 ● 100% der Requests auf reviews v1 wird auf reviews v2 gespiegelt ● Antwort von reviews v2 wird von Istio verworfen (aber im Service ausgeführt!) ... kind: DestinationRule metadata: name: reviews spec: host: reviews subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 ... kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 100 mirror: host: reviews subset: v2
  25. 25. Monitoring Quelle: istio.io
  26. 26. Tracing Quelle: istio.io
  27. 27. Service Graph Quelle: istio.io Kleiner „Big Ball of Mud“
  28. 28. Recommendations ● Marathon-Training: frühzeitig im Projekt mit Werkzeug für Service Mesh starten ● Integration in CI/CD (Zero-Downtime Deployments!) ● Resilienz besser im Sidecar als in Anwendung ● Integration Tracing/Monitoring in vorhandene Infrastruktur ● Neue Testansätze etablieren

×