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 auseinandersetzen 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.

1. Service Mesh
Kilometer 30
im
Microservice Marathon
Michael Hofmann
Hofmann IT-Consulting
info@hofmann-itconsulting.de
https://hofmann-itconsulting.de

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. 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. Schon angekommen?
Quelle: https://twitter.com/Werner/status/741673514567143424
(Werner Vogels, CTO Amazon)
Quelle: Adrian Cockcroft (Netflix) / Martin Fowler

5. Was kommt noch bei km 30?
●
Komplexität auch zwischen den Services
●
Fallacies of Distributed 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. Wohin mit der Resilience?
●
Frameworks (Hystrix (eol!), 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-Komponenten!)
– Lernkurve bzgl. vieler Frameworks bei jedem Entwickler-Team
●
Alternative: Service Mesh Tool

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. 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. 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. Service Mesh womit?
Vergleich Istio und Linkerd: https://abhishek-tiwari.com/a-sidecar-for-your-service-mesh/

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. Istio Architektur
Quelle: istio.io
Data Plane
Control Plane

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. Mixer
Quelle: istio.io

15. Pilot
Quelle: istio.io

16. Citadel
Quelle: istio.io

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. Traffic Management
Quelle: istio.io

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. 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. 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. 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. 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. 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. Monitoring
Quelle: istio.io

26. Tracing
Quelle: istio.io

27. Kiali
Quelle: istio.io
Kleiner
„Big Ball
of Mud“

28. Kiali
Quelle: istio.io

29. 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