Download to read offline
Uploaded byTEC Campus
Service Mesh Introduction - CloudNative Meetup Karlsruhe
The document is a presentation about service mesh technology, specifically focusing on Istio and its advantages in microservices architecture. It discusses the need for centralized management of cross-cutting network functions like encryption, load balancing, and monitoring, which are essential for microservices running on container platforms. Key aspects include architectural details, configuration samples, performance metrics, and the challenges of implementing service mesh solutions.
Softwareâ—¦
![Service Mesh in the Real World [Raleigh NC Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/service-mesh-real-world-191016164816-thumbnail.jpg?width=640&height=640&fit=bounds)
Service Mesh Introduction - CloudNative Meetup Karlsruhe
- 1. Stephan Fudeus SERVICE MESHINTRODUCTION Cloud Native and Kubernetes Karlsruhe Meetup
- 2. 1&1 Mail &Media Development & Technology GmbH2 Speaker 29.08.19 Stephan Fudeus § Joined 1&1 in 2005 § Long-term experience in building highly scalable multi- tenant applications § Product Owner and Technology Lead for Kubernetes Clusters of 1&1 Mail & Media § Twitter: @der_sfu
- 3. ¢ Motivation ¢ ServiceMesh in general ¢ Istio £ Beyond a single cluster £ Configuration samples £ Observability £ Performance 1&1 Mail & Media Development & Technology GmbH3 Agenda 29.08.19
- 4. SOA & Microservices 29.08.1941&1 Mail & Media Development & Technology GmbH Source: https://www.redhat.com/de/topics/microservices/what-are-microservices
- 5. Advantages of Microservices 29.08.1951&1 Mail & Media Development & Technology GmbH § Decoupling § Less local complexity § Faster development cycles § Focus on single purpose § Reusability § Scalability § …
- 6. Microservices 29.08.196 1&1 Mail& Media Development & Technology GmbH Source: https://hackernoon.com/capture-and-forward-correlation-ids-through-different-lambda-event-sources-220c227c65f5
- 7. Networks in ContainerPlatforms 29.08.197 1&1 Mail & Media Development & Technology GmbH § Physical network insufficient § Take care of basic routing and firewalling § Software Defined Networks § flexible § Usually „flat“ / „unstructured“ within a single cluster § Some infrastructural enhancements, e.g. network policies § Container Orchestrator functionalities § Rollout processes § Simple Request Routing / Load Balancing
- 8. Gap Between Networkand Applications 29.08.198 1&1 Mail & Media Development & Technology GmbH § SDN offers basic functionality § Applications need further cross-cutting network functions § Encryption: TLS § Identification & Authentication: TLS client certificates § Loadbalancing, Routing (blue/green, canary, …) § Request Tracing (incl. Timing) § Monitoring § Rate limiting § Request mirroring, Retries § Circuit Breaking § Tests: e.g. fault injection
- 9. Solution so far 29.08.1991&1 Mail & Media Development & Technology GmbH § Implementation as part of the application § language specific details § Inconsistent throughout the full landscape § High risk of errors § Re-inventing the wheel § Highly redundant § Use of frameworks § Still language-specific, thus incompatible
- 10. But …. 29.08.1910 1&1Mail & Media Development & Technology GmbH Service 1 Actual service Ribbon Hystrix Metrics Tracing Service 2 Actual service Ribbon Hystrix Metrics Tracing Service 3 Actual service Ribbon Hystrix Metrics Tracing
- 11. Solution: Service Mesh 29.08.19111&1 Mail & Media Development & Technology GmbH § Idea: Enhance functionality in an infrastructural component § Central implementation § Easier to maintain § Language agnostic
- 12. Control Plane Data Plane ServiceMesh Architecture 29.08.1912 1&1 Mail & Media Development & Technology GmbH Pod 1 Service A Pod 2 Service B Proxy Proxy Configuration Management Policies & Telemetry Certificate Management
- 13. Major Implementations 29.08.1913 1&1Mail & Media Development & Technology GmbH § Istio (1.2.x) § Linkerd2 (2.5.x) § Consul connect § …
- 14. Example: Istio 29.08.1914 1&1Mail & Media Development & Technology GmbH Control Plane Data Plane 29.08.1914 Pod 1 Service A Pod 2 Service B Pilot Mixer Citadel
- 15. General External Connectivity 29.08.19151&1 Mail & Media Development & Technology GmbH
- 16. Flexible Request Routing 29.08.19161&1 Mail & Media Development & Technology GmbH
- 17. Mesh Expansion 29.08.1917 1&1Mail & Media Development & Technology GmbH Cluster A Host A Host B Pod 1 Service A App A App A Istio Control Plane
- 18. Multi Cluster 29.08.1918 1&1Mail & Media Development & Technology GmbH Cluster A Pod 1 Service A Istio Control Plane Cluster B Pod 2 Service B Istio Control Plane Root CA Gateway
- 19. Configuration Objects 29.08.1919 1&1Mail & Media Development & Technology GmbH VirtualService DestinationRuleClient Pod Destination Pod Relevant features • Routing • Timeouts • Retries • Fault injection • Aborts • Delays • Mirroring Relevant features • Circuit breaking • Routing • Load balancing
- 20. Configuration Objects 29.08.1920 1&1Mail & Media Development & Technology GmbH Client Pod ServiceEntry External Service
- 21. Configuration Samples -Routing 29.08.1921 1&1 Mail & Media Development & Technology GmbH
- 22. Configuration Samples –Fault/Delay Injection 29.08.1922 1&1 Mail & Media Development & Technology GmbH
- 23. Configuration Samples –Mirroring / Timeouts 29.08.1923 1&1 Mail & Media Development & Technology GmbH
- 24. Configuration Samples –Circuit Breaking 29.08.1924 1&1 Mail & Media Development & Technology GmbH
- 25. Additional Aspects 29.08.1925 1&1Mail & Media Development & Technology GmbH § Security policies § Transport security § Authentication / Authorization § Policies and Telemetry § Whitelists and Blacklists § Rate limiting § Header rewrites and redirects
- 26. Observability with Kiali 29.08.19261&1 Mail & Media Development & Technology GmbH
- 27. Overhead 29.08.1927 1&1 Mail& Media Development & Technology GmbH § Official numbers § The Envoy proxy adds 8ms to the 90th percentile latency. § The Envoy proxy uses 0.6 vCPU and 50 MB memory per 1000 requests per second going through the proxy.