CloudNative Days Tokyo 2019: Understanding Envoy

https://cloudnativedays.jp/cndt2019/

Transcript

1. Taiki Ono Cloud Native Days Tokyo 2019 Understanding Envoy
2. Agenda • What is Envoy • Envoy use cases 2
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. 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. 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. 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. 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. Who is Envoy (2018) 8
9. Envoy Architecture 9
10. Envoy use cases 1: Extending SmartStack
11. EnvoyCon 2018 / How to DDOS yourself with Envoy: https://sched.co/HDbQ
12. EnvoyCon 2018 / How to DDOS yourself with Envoy: https://sched.co/HDbQ
13. EnvoyCon 2018 / How to DDOS yourself with Envoy: https://sched.co/HDbQ
14. Envoy use cases 2: Replacing HW LBs
15. EnvoyCon 2018 / Running Envoy as an Edge Proxy: https://sched.co/HDRr
16. EnvoyCon 2018 / Running Envoy as an Edge Proxy: https://sched.co/HDRr
17. EnvoyCon 2018 / Running Envoy as an Edge Proxy: https://sched.co/HDRr
18. Envoy use cases 3: Containers/VMs hybrid workload
19. EnvoyCon 2018 / Building + Operating Service Mesh: https://sched.co/HDdu
20. EnvoyCon 2018 / Building + Operating Service Mesh: https://sched.co/HDdu
21. Envoy on VMs • 公式に Debian, RPM パッケージ等は存在しないがサードパーティが提供して いるものがある ◦ https://getenvoy.io/ ◦ カスタムフィルターが存在する場合は今のところ自分たちでビルドする必要がある(公式のビ ルド用 Docker image は使える) • Hot restart だけ公式リポジトリにあるスクリプトを参考に作る必要がある ◦ 以前はバージョン間の hot restart 非互換があったが、hot restart の設計が変わって安定し たっぽい • VM ベースの構成からコンテナベースの構成へマイグレーションする時とか にも利用できる ◦ あるいは on-prems から public cloud へのマイグレーション 21
22. まとめ Q&A • 少数の機能の実現でよければ Envoy 単体を使ってサービスメッシュを構築す るのは意外と少ないコストでできマイグレーションもしやすい ◦ Observability だけ、gRPC トラフィックの管理だけ、等スコープを絞る ◦ 一方、各製品・マネージドサービスも進化・新しく登場しているので比較検証するのがよい • どこを config ソースにするかが決まれば xDS API を通じて Envoy に伝播さ せるのみ ◦ GH: envoyproxy/go-control-plane, envoyproxy/java-control-plane • VM ベースのワークロードでも Envoy は活用できる Q&A: @taiki45 でも対応