CloudNative Days Tokyo 2019: Understanding Envoy

Transcript

1. 1.

   Taiki Ono Cloud Native Days Tokyo 2019 Understanding Envoy

2. 2.

   Agenda • What is Envoy • Envoy use cases 2

3. 3.

   State of microservice networking in industry • Languages and frameworks.

   • Protocols (HTTP/1, HTTP/2, gRPC, databases, caching, etc.). • Infrastructures (IaaS, CaaS, on premise, etc.). • Intermediate load balancers (AWS ELB, F5, etc.). • Per language libraries for service calls. ◦ Inconsistent observability output (stats, tracing, and logging). ◦ Implementations (often partial) of retry, circuit breaking, rate limiting, timeouts, and other distributed systems best practices. ◦ Authentication and Authorization. • Libraries are incredibly painful to upgrade (Think CVEs). 3
4. 4.

   What is Envoy The network should be transparent to applications.

   When network and application problems do occur it should be easy to determine the source of the problem. 4
5. 5.

   Envoy design goals • Out of process architecture • High

   performance / low latency code base • L3/L4 filter architecture • HTTP L7 filter architecture • HTTP/2 first • Service discovery and active/passive health checking • Advanced load balancing • Best in class observability (stats, logging, and tracing) • AuthN/AuthZ • Edge proxy 5
6. 6.

   Envoy config management via xDS APIs • Envoy is a

   universal data plane • xDS == * Discovery Service (various configuration APIs). E.g.,: ◦ LDS == Listener Discovery Service, CDS == Cluster Discovery Service • Both gRPC streaming and JSON/YAML REST via proto3! • Central management system can control a fleet of Envoys avoiding per-proxy config file hell • Global bootstrap config for every Envoy, rest taken care of by the management server • Envoys + xDS + management system == fleet wide traffic management distributed system 6
7. 7.

   Why Envoy • Quality + velocity • Extensibility ◦ L4/L7

   filters, Access loggers, Tracers, Health checkers, Transport sockets, Retry policy, Resource monitors, Stats sink ◦ See /source/extensions directory • Eventually consistent configuration API • No “open core”/paid premium version. It’s all there. • Community, community, community 7
8. 8.

   Who is Envoy (2018) 8

9. 9.

   Envoy Architecture 9

10. 10.

    Envoy use cases 1: Extending SmartStack

11. 11.

    EnvoyCon 2018 / How to DDOS yourself with Envoy: https://sched.co/HDbQ

12. 12.

    EnvoyCon 2018 / How to DDOS yourself with Envoy: https://sched.co/HDbQ

13. 13.

    EnvoyCon 2018 / How to DDOS yourself with Envoy: https://sched.co/HDbQ

14. 14.

    Envoy use cases 2: Replacing HW LBs

15. 15.

    EnvoyCon 2018 / Running Envoy as an Edge Proxy: https://sched.co/HDRr

16. 16.

    EnvoyCon 2018 / Running Envoy as an Edge Proxy: https://sched.co/HDRr

17. 17.

    EnvoyCon 2018 / Running Envoy as an Edge Proxy: https://sched.co/HDRr

18. 18.

    Envoy use cases 3: Containers/VMs hybrid workload

19. 19.

    EnvoyCon 2018 / Building + Operating Service Mesh: https://sched.co/HDdu

20. 20.

    EnvoyCon 2018 / Building + Operating Service Mesh: https://sched.co/HDdu

21. 21.

    Envoy on VMs • 公式に Debian, RPM パッケージ等は存在しないがサードパーティが提供して いるものがある ◦

    https://getenvoy.io/ ◦ カスタムフィルターが存在する場合は今のところ自分たちでビルドする必要がある(公式のビ ルド用 Docker image は使える) • Hot restart だけ公式リポジトリにあるスクリプトを参考に作る必要がある ◦ 以前はバージョン間の hot restart 非互換があったが、hot restart の設計が変わって安定し たっぽい • VM ベースの構成からコンテナベースの構成へマイグレーションする時とか にも利用できる ◦ あるいは on-prems から public cloud へのマイグレーション 21
22. 22.

    まとめ Q&A • 少数の機能の実現でよければ Envoy 単体を使ってサービスメッシュを構築す るのは意外と少ないコストでできマイグレーションもしやすい ◦ Observability だけ、gRPC

    トラフィックの管理だけ、等スコープを絞る ◦ 一方、各製品・マネージドサービスも進化・新しく登場しているので比較検証するのがよい • どこを config ソースにするかが決まれば xDS API を通じて Envoy に伝播さ せるのみ ◦ GH: envoyproxy/go-control-plane, envoyproxy/java-control-plane • VM ベースのワークロードでも Envoy は活用できる Q&A: @taiki45 でも対応