Navigating the service mesh landscape with Istio, Consul Connect, and Linkerd
•Télécharger en tant que PPTX, PDF•
8 j'aime•5,168 vues
The document discusses various service mesh options including Linkerd, Consul Connect, Istio, and AWS App Mesh. It provides an overview of each solution, describing their key features and strengths/opportunities. It emphasizes that the service mesh approach is useful for managing inter-service communication and that implementations are still evolving. It recommends starting simply and iteratively adopting capabilities to match needs.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Navigating the service mesh landscape with Istio, Consul Connect, and Linkerd
Similaire à Navigating the service mesh landscape with Istio, Consul Connect, and Linkerd (20)
Plus de Christian Posta
Plus de Christian Posta (20)
Dernier
Dernier (20)
Navigating the service mesh landscape with Istio, Consul Connect, and Linkerd
- 1. 1 | Copyright © 2019 Service-mesh options with Linkerd, Consul, Istio and AppMesh Christian Posta Global Field CTO, Solo.io OSCON 2019
- 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 | 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 | Copyright © 2019 Move fast, safely https://puppet.com/resources/whitepaper/state-of-devops-report
- 5. 5 | Copyright © 2019 As we move to services architectures, we push the complexity to the space between our services.
- 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 | Copyright © 2019 …Continued… • Routing between services (adaptive, zone-aware) • Deadlines • Back pressure • Outlier detection • Health checking • Traffic shaping • Request shadowing
- 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 | 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 | 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 | Copyright © 2019 But I’m using Vert.x! • vertx-circuit-breaker • vertx-service-discovery • vertx-dropwizard-metrics • vertx-zipkin? • ….. • ......
- 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 | 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 | 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 | Copyright © 201915 | Copyright © 2019 Foundation for a solution
- 16. 16 | Copyright © 2019 Meet Envoy Proxy http://envoyproxy.io
- 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 | Copyright © 2019
- 19. 19 | Copyright © 2019
- 20. 20 | Copyright © 2019 Deployed as a service proxy:
- 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 | Copyright © 201922 | Copyright © 2019 Service-mesh architecture
- 23. 23 | Copyright © 2019
- 24. 24 | Copyright © 2019
- 25. 25 | Copyright © 2019
- 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 | Copyright © 201927 | Copyright © 2019 Exploring service-mesh implementations
- 28. 28 | Copyright © 2019 Meet Linkerd http://linkerd.io
- 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 | Copyright © 2019
- 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 | Copyright © 2019 Meet Consul Connect http://consul.io
- 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 | Copyright © 2019
- 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 | Copyright © 2019 Meet Istio.io http://istio.io
- 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 | Copyright © 2019
- 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 | Copyright © 2019 Meet AWS App Mesh https://aws.amazon.com/app-mesh/
- 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 | Copyright © 2019
- 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 | Copyright © 201944 | Copyright © 2019 Comparisons
- 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 | 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 | Copyright © 2019 Easiest way to get started with service mesh is with… https://supergloo.solo.io
- 48. 48 | Copyright © 2019 https://supergloo.solo.io
- 49. 49 | Copyright © 2019 Service Mesh Interface (SMI) https://github.com/deislabs/smi-spec https://supergloo.solo.io https://servicemeshhub.io
- 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 | 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 | Copyright © 2019 CHRISTIAN POSTA @christianposta christian@solo.io https://blog.christianposta.com https://slideshare.net/ceposta
- 53. 53 | Copyright © 201953 | Copyright © 2019 @soloio_inc
Notes de l'éditeur
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.
- Get back to first principles. Focus on principles, patterns, methodologies. Tools will help, but you cannot start with tools.