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.

Navigating the service mesh landscape with Istio, Consul Connect, and Linkerd

1 154 vues

Publié le

Service mesh has hit the cloud native computing community like a storm, and we’re starting to see gradual adoption across the enterprise. There are a handful of open source service mesh implementations to choose from, including Istio, Consul Connect, and Linkerd.

Christian Posta details why and when you may want to use a service mesh versus when you may want to just stick with a library, Netflix OSS, or application approach. He digs into three popular open source service mesh implementations and explores their goals, strengths, and weaknesses. You’ll come away with a good foundation from which to explore service mesh technology and ask the right questions to get to the right answer for them.

Publié dans : Logiciels
  • Soyez le premier à commenter

Navigating the service mesh landscape with Istio, Consul Connect, and Linkerd

  1. 1. 1 | Copyright © 2019 Service-mesh options with Linkerd, Consul, Istio and AppMesh Christian Posta Global Field CTO, Solo.io OSCON 2019
  2. 2. 2 | Copyright © 2019 CHRISTIAN POSTA • Field CTO @ solo.io • Author of a few books • Contributor to many open-source projects • Architect, blogger, speaker, mentor, leader https://bit.ly/istio-in-action @christianposta christian@solo.io https://blog.christianposta.com https://slideshare.net/ceposta
  3. 3. 3 | Copyright © 2019 Flow of talk • What’s the problem we’re addressing with a service mesh? • What is a service mesh? Previous approaches / pros / cons • Generic service-mesh architecture • Explore service-mesh implementations • Guidance for service-mesh adoption
  4. 4. 4 | Copyright © 2019 Move fast, safely https://puppet.com/resources/whitepaper/state-of-devops-report
  5. 5. 5 | Copyright © 2019 As we move to services architectures, we push the complexity to the space between our services.
  6. 6. 6 | Copyright © 2019 Challenges in a cloudy world • Service discovery • Retries • Timeouts • Load balancing • Rate limiting • Thread bulk heading • Circuit breaking • Security
  7. 7. 7 | Copyright © 2019 …Continued… • Routing between services (adaptive, zone-aware) • Deadlines • Back pressure • Outlier detection • Health checking • Traffic shaping • Request shadowing
  8. 8. 8 | Copyright © 2019 …Continued… • Edge/DMZ routing • Surgical / fine / per-request routing • A/B rollout • Internal releases / dark launches • Fault injection • Stats, metric, collection • Logging • Tracing
  9. 9. 9 | Copyright © 2019 • 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) Microservices Patterns
  10. 10. 10 | Copyright © 2019 But 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 • spring-cloud-netflix-spectator • spring-cloud-netflix-hystrix-stream • ….. • @Enable....150differentThings
  11. 11. 11 | Copyright © 2019 But I’m using Vert.x! • vertx-circuit-breaker • vertx-service-discovery • vertx-dropwizard-metrics • vertx-zipkin? • ….. • ......
  12. 12. 12 | Copyright © 2019 Screw Java - I’m using NodeJS! JavaScript is for rookies, I use Go! But python is so pretty! I prefer unreadability… Perl for me!
  13. 13. 13 | Copyright © 2019 • Require specific language to bring in new services • A single language doesn’t fit for all use cases • How do you patch/upgrade/manage lifecycle? • Need strict control over application library choices Some drawbacks to this approach?
  14. 14. 14 | Copyright © 2019 Let’s abstract this functionality and apply to all services out of process • Allow heterogeneous architectures • Remove application-specific implementations of this functionality • Consistently enforce these properties • Correctly enforce these properties • Opt-in as well as safety nets
  15. 15. 15 | Copyright © 201915 | Copyright © 2019 Foundation for a solution
  16. 16. 16 | Copyright © 2019 Meet Envoy Proxy http://envoyproxy.io
  17. 17. 17 | Copyright © 2019 Envoy Proxy: • written in C++, highly parallel, non-blocking • L4 / L7 service proxy (HTTP1, HTTP2, gRPC, Kafka, Redis, Mongo, Dynamo, etc) • zone aware, least request load balancing • circuit breaking / outlier detection • retries, retry policies • timeout (including budgets) • traffic shadowing • rate limiting • access logging, statistics collection • dynamic configuration through standard interfaces
  18. 18. 18 | Copyright © 2019
  19. 19. 19 | Copyright © 2019
  20. 20. 20 | Copyright © 2019 Deployed as a service proxy:
  21. 21. 21 | Copyright © 2019 A service mesh is decentralized application- networking infrastructure between your services that provides resiliency, security, observability, and routing control.
  22. 22. 22 | Copyright © 201922 | Copyright © 2019 Service-mesh architecture
  23. 23. 23 | Copyright © 2019
  24. 24. 24 | Copyright © 2019
  25. 25. 25 | Copyright © 2019
  26. 26. 26 | Copyright © 2019 Service mesh technologies typically provide: • Service discovery / Load balancing • Secure service-to-service communication • Traffic control / shaping / shifting • Policy / Intention based access control • Traffic metric collection • Service resilience • API / programmable interface
  27. 27. 27 | Copyright © 201927 | Copyright © 2019 Exploring service-mesh implementations
  28. 28. 28 | Copyright © 2019 Meet Linkerd http://linkerd.io
  29. 29. 29 | Copyright © 2019 Linkerd2 • Backed by Buoyant / CNCF • Kubernetes specific • Control plane (go) / custom data plane (rust) • Latest release 2.4 • Strong focus on observing top-level network metrics • Resilience, timeouts, retry budgets • Always-on mTLS
  30. 30. 30 | Copyright © 2019
  31. 31. 31 | Copyright © 2019 Linkerd2 • Purpose built, Kubernetes only • Uses CRD for configurations • High performance characteristics • Great user/getting-started experience • Open, welcoming community • Observability, basic resilience • Secure by default • Deployed transparently to app Strengths • Limited feature set (at the moment… more to come) • Missing traffic routing, policy enforcement, circuit breakers • Kubernetes-only • Multi-cluster support Opportunities
  32. 32. 32 | Copyright © 2019 Meet Consul Connect http://consul.io
  33. 33. 33 | Copyright © 2019 Consul Connect • Backed by HashiCorp • Control plane (consul server) / data plane (proxies/app) • Part of Consul 1.2 release, June 2018 (latest is 1.5.2) • Strong focus on L4 Identity (SPIFFE) • Easy to configure transport encryption (mTLS) • Service segmentation, intention-based ACL policy • Optional use of Envoy Proxy • Native app integration for latency/performance sensitive apps
  34. 34. 34 | Copyright © 2019
  35. 35. 35 | Copyright © 2019 Consul Connect • Built on Consul: stable, critical piece of software • Solves the identity management challenges in dynamic applications • Hybrid environment support • Optional Envoy Proxy • Multi-cluster/site foundations • Vault support for certificate management Strengths • Application config/code impact (not transparent to app, cannot use k8s dns) • Have to manage separate CP data store • does not use CRDs on k8s • No distributed tracing Opportunities
  36. 36. 36 | Copyright © 2019 Meet Istio.io http://istio.io
  37. 37. 37 | Copyright © 2019 Istio • Control plane / data plane (Envoy Proxy) • 1.1 March 2019 • Collaboration between Google, IBM, Lyft, VMWare, Red Hat, et al. • Based on Envoy proxy • mTLS, policy based ACL, resilience, observability, traffic control • Kubernetes native with other platform support • Large community
  38. 38. 38 | Copyright © 2019
  39. 39. 39 | Copyright © 2019 Istio • Large, vibrant community • Backed by Google, et. al. • Large feature set • Based on Envoy • Flexible deployment options • Out of the box Ingress • Multi-cluster support Strengths • Performance / overhead improvements • Architecture improvements • Focus on iterative adoption • Continue improvement to documentation • Reduce magic Opportunities
  40. 40. 40 | Copyright © 2019 Meet AWS App Mesh https://aws.amazon.com/app-mesh/
  41. 41. 41 | Copyright © 2019 AWS App Mesh • Backed by AWS • Control plane (managed) / data plane (Envoy Proxy) • Announced Nov 2018, GA March 2019 • Main functionality is around weighted traffic routing • Supported across deployment platforms • Continuing to add more features
  42. 42. 42 | Copyright © 2019
  43. 43. 43 | Copyright © 2019 AWS App Mesh • Managed control plane • Built on Envoy Proxy • Supports multiple deployment platforms (EC2, ECS, EKS, Kubernetes) • Focus on basic traffic shifting • Ties in with rest of AWS infrastructure • Free to use on AWS Strengths • AWS Only • Very limited control-plane capabilities • No visibility to control plane behavior • No mTLS, Policy, enforcement fine- grained traffic control • Manually configure Envoy for metrics- collection/CloudWatch integration Opportunities
  44. 44. 44 | Copyright © 201944 | Copyright © 2019 Comparisons
  45. 45. 45 | Copyright © 2019 Anecdotal comparisons: Benchmarking Istio and Linkerd CPU: https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-c36287e32781 Benchmarking Istio and Linkerd at Scale (follow up) https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-at-scale-5f2cfc97c7fa
  46. 46. 46 | Copyright © 2019 Wrapping up - Ignore comparisons and anecdotes. Focus on: • Service mesh approach is the right approach, implementations still evolving • Solve today’s pain with as little technology as you can • Invest in the data plane (Envoy proxy) • Ingress-first approach: API Gateways (like Gloo, built on Envoy) can give you service- mesh-like capabilities with a fraction of the complexity and risk • Iteratively adopt service-mesh capabilities (and commensurate deployment footprint) • Abstract service-mesh implementation details, configuration, opinions
  47. 47. 47 | Copyright © 2019 Easiest way to get started with service mesh is with… https://supergloo.solo.io
  48. 48. 48 | Copyright © 2019 https://supergloo.solo.io
  49. 49. 49 | Copyright © 2019 Service Mesh Interface (SMI) https://github.com/deislabs/smi-spec https://supergloo.solo.io https://servicemeshhub.io
  50. 50. 50 | Copyright © 2019 Exploring service mesh implementations “I used SuperGloo because it was super simple to get both services meshes bootstrapped quickly, with almost no effort on my part. We’re not using SuperGloo in production, but it was perfect for a task like this. It was literally two commands per mesh. I used two clusters for isolation— one for Istio, and one for Linkerd.” https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-c36287e32781
  51. 51. 51 | Copyright © 2019 Additional reading • Istio the easy way https://medium.com/solo-io/istio-the-easy-way-de66e6eba4a1 • Linkerd vs Istio https://medium.com/solo-io/linkerd-or-istio-6fcd2aad6e42 • SuperGloo Open API and Service Mesh Orchestration https://medium.com/solo-io/https-medium-com-solo-io-supergloo-ff2aae1fb96f • Follow up: Benchmarking Istio and Linkerd at Scale • https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-at-scale- 5f2cfc97c7fa • Linkerd April 2019 Community Meeting https://buoyant.io/resources/april-2019-linkerd-community-meeting-recap/ • AWS AppMesh FAQ https://aws.amazon.com/app-mesh/faqs/ • Consul Connect Intro https://www.hashicorp.com/resources/consul-connect-announcement-mitchell-hashimoto • Consul Connect Roadmap https://www.hashicorp.com/blog/roadmap-preview-what-s-next-for-consul-service-mesh
  52. 52. 52 | Copyright © 2019 CHRISTIAN POSTA @christianposta christian@solo.io https://blog.christianposta.com https://slideshare.net/ceposta
  53. 53. 53 | Copyright © 201953 | Copyright © 2019 @soloio_inc

×