CloudNative Days Tokyo 2019: Understanding Envoy

44e6e0e9bcc3d8279020aad563f16f34?s=47 taiki45
July 23, 2019

CloudNative Days Tokyo 2019: Understanding Envoy



July 23, 2019


  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 21.

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

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

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