Istio and the Service Mesh Architecture

Transcript

1. Istio and the Service Mesh Architecture DevOps BKK 2018

2. About me • Manatsawin Hanmongkolchai • Junior Architect at Wongnai

3. How I sold Istio to my team

4. How Wongnai monitor microservices

5. Microservice monitoring • In-service metrics eg. controller time

6. Microservice monitoring • AWS X-Ray SDK

7. Microservice monitoring • Sentry

8. Microservice monitoring • ELB Error Rate

9. Microservice monitoring These must be integrated into your service AWS

   X-Ray

10. Microservice monitoring The problem in microservice world • Service can

    be written in many languages. Not all tools support every languages

11. Microservice monitoring The problem in microservice world • People in

    a rush skip implementing proper monitoring

12. Meet Istio

13. Service mesh Istio handle interservice connection Sidecar

14. How Istio sidecar work? Istio use admission controller to install

    2 containers in your pod

15. How Istio sidecar work? 1. Init container to setup transparent

    proxy iptables rule (as root) 2. Envoy running alongside your app as the transparent proxy

16. What Istio can do for you Monitoring • Network calls

    • Tracing

17. Network monitoring Istio provide insight into your network in layer

    7

18. Total requests 4xx 5xx

19. Request count of service Response time

20. Service network monitoring Measured client side Request count Success rate

    Resp. time Speed (for TCP) Measured server side

21. Who call me?

22. Distributed Tracing • All incoming/outgoing HTTP calls are traced to

    Jaeger • Needs to propagate OpenTracing headers from incoming call to outgoing call to track calls correctly

23. Distributed Tracing • Easiest way is to just integrate Zipkin

    OpenTracing into your app

24. Distributed Tracing

25. Distributed Tracing

26. What Istio can do for you • Traffic Management ◦

    Routing ▪ Traffic Shifting ▪ Mirror ◦ Fault Injection ◦ Circuit Breaker

27. Routing • Kubernetes service operates in Layer 4 Cluster IP

    Backend Backend Backend Req Req Req Req Req Req

28. Routing • Istio operate in layer 7 and can do

    per-call load balancing Envoy Req Req Req Req Req Req Backend Backend Backend

29. Split traffic • Split traffic between service (eg. 1% to

    new version)

30. Mirror traffic • Test in production by cloning traffic Envoy

    Live version Test version Req

31. Fault Injection • Intentionally making service worse • Why? Let’s

    hear a story

32. Fault Injection Site Reliability Engineering How Google runs production systems

    landing.google.com /sre/book/

33. #WongnaiIsHiring • Wongnai is looking for our first Site Reliability

    Engineer • careers.wongnai.com

34. Chubby

35. Fault Injection Over time, we found that the failures of

    the global instance of Chubby consistently generated service outages.

36. Fault Injection As it turns out, true global Chubby outages

    are so infrequent that service owners began to add dependencies to Chubby assuming that it would never go down.

37. Fault Injection The solution to this Chubby scenario is interesting:

    SRE makes sure that global Chubby meets, but does not significantly exceed, its service level objective.

38. Fault Injection In any given quarter, if a true failure

    has not dropped availability below the target, a controlled outage will be synthesized by intentionally taking down the system.

39. Fault Injection • Slow down services ◦ Delay 80% of

    requests for 5 seconds • Make errors ◦ Return 500 error code for 80% of requests

40. Circuit Breaker Remove a backend from service if it return

    too many errors in a row Frontend Backend Work Queue 503 Timeout F5

41. Summary Istio provide visibility and configurability to your network. This

    is traditionally done by adding library, but in a microservice world you need a cross language solution

42. The catch Here’s what we found while moving to Istio

    • While requiring zero code changes, your service must already be well behaved cloud application

43. The catch • Do not connect directly to pod IP

    (eg. no service discovery - just use cluster IP and avoid headless service)

44. The catch • Do not mix port type in the

    cluster (eg. don’t run HTTP server on port 6379 with another pod running TCP service at the same port)

45. The catch • Set the Host header to the destination.

    Don’t connect to gateway and set Host header to cooking. ◦ This case is really hard to debug...

46. The catch • External services (ie. outside Kubernetes) but in

    the capturing IP range must have ServiceEntry defined ◦ ServiceEntry is cluster-wide

47. Slides on speakerdeck.com/whs