ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

LEARN ENVOY - Dynamic Configuration / Service Discovery Integration

www.envoyproxy.io

(ちゃんとした翻訳・要約ではなく、読みながらのメモです)

  • envoy は様々な Service Discovery Software と Integrate できる
  • envoy の core concept は data plane を controll plane から分離し、control plane から source of truth となる configuration を 変更できることである
  • まずは control plane が service discovery に接続できる必要があり、それは以下の 3 step に分けられる

  • Decide on a control plane implementation

  • Publish service definitions to Envoy clusters
  • Publish hosts/containers/instances to Envoy endpoints

いうても control plane まだないぞ、みたいな気持ちで続きを読んでいく。

いかなる control plane も Envoy v2 xDS APIs を実装する必要がある。

www.envoyproxy.io

istio の場合 pilot がそれに該当する。

その後の CDS / EDS の話ははいという感じ。

最後に、Service Discovery はめちゃくちゃたくさんの問い合わせがくるのでどう分割するかという話。データセンター、地域で分割したり、サービスのニーズによって分割したり。


さて、まだ Control Plane を持っていないのだが、現状 Kubernetes 上で Service Discovery は誰が担っているかというと、k8s service になる。

k8s service が 実際に転送先の pod の IP の list を持っていて、pod 生き死にすると、新しい endpoint を service が知るので、envoy cluster 側は 転送したい cluster IP だけ知っていればよく、かつそれは kube-dns で引ける。

そう考えるとこのパターンだと service discovery という感じではなく、load balancing は service が行うことになるので、envoy としては cluster が単一の宛先を覚えてるだけですね。

istio が入るとこのへんどう変わってくるんだろうか。なんか envoy だけまずは知ろうとしてるけど早くも control plane の話出てきたし順番間違ったかな。まぁこのまま進むけど。