Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Introduction to Istio Service Mesh

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 41 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Introduction to Istio Service Mesh (20)

Anzeige

Aktuellste (20)

Introduction to Istio Service Mesh

  1. 1. Introduction to Istio Service Mesh Georgios Andrianakis Senior Software Engineer - Red Hat
  2. 2. We of course need to start talking about Microservices
  3. 3. Microservices are Distributed Systems They introduce non-trivial complexity into the space between our microservices - the network
  4. 4. Distributed Systems Challenges ● Resilience and fault tolerance ○ Retries ○ Timeouts ○ Circuit Breaker ● Service Discovery ○ Load Balancing ● Observability ○ Logs ○ Metrics ○ Traces ● Security ● Policy Enforcement ● Traffic Shaping ○ Rate Limiting ○ Canary Deployments ○ A/B Testing ○ Fault injection ○ Traffic Shadowing
  5. 5. HOW TO DEAL WITH THE COMPLEXITY?
  6. 6. • Netflix Hystrix (circuit breaking / bulk heading) • Netflix Zuul (edge router) • Netflix Ribbon (client-side service discovery / load balance) • Netflix Eureka (service discovery registry) • Brave / Zipkin (tracing) • Netflix spectator / atlas (metrics) Traditional Approach
  7. 7. I’m using Spring • spring-cloud-netflix-hystrix • spring-cloud-netflix-zuul • spring-cloud-netflix-eureka-client • spring-cloud-netflix-ribbon • spring-cloud-netflix-atlas • ...... • @Enable....150 different Things
  8. 8. Traditional approach Spring Cloud Config Server Service Netflix Eureka Netflix Ribbon Config Service Config Service Config Svc Discovery Svc Discovery Svc Discovery Routing Routing Routing Netflix Zuul Server Circuit Breaker Circuit Breaker Circuit Breaker Tracing Tracing Tracing ZipKin Server INFRASTRUCTURE
  9. 9. Drawbacks of this approach ● Need an implementation for each combination of runtime/framework ○ Might end up forcing specific languages / frameworks on teams ● Need to maintain, upgrade, retire ○ Different teams need to sync to do this correctly ● Classpath / namespace pollution ○ We end up with large deployables even for very small microservices
  10. 10. IS THERE A BETTER WAY TO TACKLE THESE ISSUES?
  11. 11. Move horizontal concerns out of the application and into the platform. Apply to all services regardless of implementation Platform Approach
  12. 12. • Individual microservices can better focus on providing business value • Allow heterogeneous architectures • Consistently and correctly enforce approaches to microservices challenges Benefits of the Platform Approach
  13. 13. MyService Monitoring Tracing API Discovery Invocation Resilience Pipeline Authentication Logging Elasticity Does vanilla Kubernetes have us covered?
  14. 14. Istio fills in the gaps left open (deliberately) by Kubernetes Platform approach
  15. 15. HOW IS THIS ACCOMPLISHED?
  16. 16. Pod Container Sidecar Container Pod Container Service C Sidecar Container Pod Container Service B Sidecar Container The sidecars intercepts all network traffic Sidecar on Kubernetes Service A The sidecar is the secret sauce used to make applications capable of leveraging the platforms capabilities
  17. 17. Pod Container Sidecar Container Pod Container Service C Sidecar Container Pod Container Service B Sidecar Container Service A Envoy is the sidecar used in Istio
  18. 18. The proliferation of sidecars introduces another issue: How do we reason about a fleet of these service proxies in a large cluster?
  19. 19. A service mesh is decentralized application- networking infrastructure between your services that provides resilience, security, observability, and routing control. A service mesh is comprised of a data plane and a control plane. Enter the Service Mesh
  20. 20. Meet Istio http://istio.io A control plane for service proxies
  21. 21. svcA Envoy Pod Service A svcB Envoy Service B Control Plane API Discovery & Config data to Envoys Policy checks, Telemetry, Quota, Rate Limiting Control flow during request processing TLS certs to Envoy Traffic is transparently intercepted and proxied. App is unaware of Envoy’s presence Pilot Mixer Citadel Istio High Level Architecture
  22. 22. Let’s compare solutions to Distributed System challenges ● Traditional Approach ● Istio
  23. 23. SERVICE A SERVICE B CIRCUIT BREAKERS WITHOUT ISTIO SERVICE C CB CB coupled to the service code
  24. 24. POD SERVICE A ENVOY POD SERVICE B ENVOY POD SERVICE C ENVOY CIRCUIT BREAKERS WITH ISTIO transparent to the services
  25. 25. POD SERVICE A ENVOY POD SERVICE B ENVOY POD SERVICE C ENVOY TIMEOUTS AND RETRIES WITH ISTIO configure timeouts and retries, transparent to the services timeout: 10 sec retry: 5 timeout: 15 sec retry: 5
  26. 26. SERVICE A SERVICE B SECURE COMMUNICATION WITHOUT ISTIO SERVICE C TLS TLS TLS TLS coupled to the service code
  27. 27. SECURE COMMUNICATION WITH ISTIO POD SERVICE A ENVOY POD SERVICE B ENVOY POD SERVICE C ENVOY mutual TLS authentication, transparent to the services TLS TLS
  28. 28. Gateway Service SERVICE A SERVICE B:1 DYNAMIC ROUTING WITHOUT ISTIO SERVICE B:2 Netflix Zuul Server custom code to enable dynamic routing
  29. 29. POD SERVICE A ENVOY POD SERVICE B:v2 ENVOY CANARY DEPLOYMENT WITH ISTIO POD SERVICE B:v1 ENVOY User: George Everyone else
  30. 30. POD SERVICE A ENVOY POD SERVICE B:v2 ENVOY A/B TESTING WITH ISTIO POD SERVICE B:v1 ENVOY 50% traffic 50% traffic
  31. 31. POD SERVICE A ENVOY POD SERVICE B:v2 ENVOY DARK LAUNCHES WITH ISTIO POD SERVICE B:v1 ENVOY 100% traffic mirror traffic
  32. 32. CHAOS ENGINEERING WITHOUT ISTIO SERVICE A SERVICE B SERVICE C Netflix Chaos Monkeys Netflix Spinnaker random termination
  33. 33. POD SERVICE A ENVOY POD SERVICE B ENVOY POD SERVICE C ENVOY CHAOS ENGINEERING WITH ISTIO inject delays, transparent to the services 10 sec delay in 10% of requests
  34. 34. inject protocol-specific errors, transparent to the services POD SERVICE A ENVOY POD SERVICE B ENVOY POD SERVICE C ENVOY CHAOS ENGINEERING WITH ISTIO HTTP 500 in 5% of requests
  35. 35. SERVICE A SERVICE B SERVICE C DISTRIBUTED TRACING WITHOUT ISTIO Spring Sleuth ZipKin Spring Sleuth ZipKin Spring Sleuth ZipKin code to enable dynamic tracing
  36. 36. POD SERVICE A ENVOY POD SERVICE B ENVOY POD SERVICE C ENVOY DISTRIBUTED TRACING WITH ISTIO & JAEGER discovers service relationships and process times, transparent to the services SERVICE A SERVICE B SERVICE C 210 ms 720 ms 930 ms
  37. 37. Time for some eye candy
  38. 38. Thank you! Twitter: @geoand86 Slides: http://slideshare.net/GeorgiosAndrianakis Further reading • http://envoyproxy.io • http://istio.io • https://medium.com/@mattklein123/ • http://blog.christianposta.com/istio-workshop/slides/ • http://blog.christianposta.com/tags/#istio • http://bit.ly/istio-tutorial

×