Service Topology による効率的なロードバランシング #jawsug_ct / JAWS Container SIG 16th

332f89cc697355902a817506b6995f2b?s=47 y_taka_23
January 23, 2020

Service Topology による効率的なロードバランシング #jawsug_ct / JAWS Container SIG 16th

JAWS コンテナ支部 #16 で使用したスライドです。

332f89cc697355902a817506b6995f2b?s=128

y_taka_23

January 23, 2020
Tweet

Transcript

  1. 4.

    マルチ AZ クラスタの留意点 • 障害時の可用性 ◦ AZ がダウンすると複数の Node が同時に死ぬ

    ◦ 複数 Node 上に分散していても全滅の危険 • 通信のレイテンシ ◦ Service から Pod への振り分けはラウンドロビン ◦ Pod 間の通信で AZ を跨ぎたくない
  2. 5.

    マルチ AZ クラスタの留意点 • 障害時の可用性:Topology Spread ◦ AZ がダウンすると複数の Node

    が同時に死ぬ ◦ 複数 Node 上に分散していても全滅の危険 • 通信のレイテンシ:Service Topology ◦ Service から Pod への振り分けはラウンドロビン ◦ Pod 間の通信で AZ を跨ぎたくない
  3. 8.
  4. 10.
  5. 11.
  6. 12.
  7. 13.
  8. 15.

    Service Topology とは • Kubernetes v1.17 の α 機能 •

    ネットワークを Node 上の Label で表現 ◦ AWS 上では自動で付与されるラベルが使える • 効率的な Pod-Pod 間の通信が可能に ◦ ネットワーク的に「近い」Pod を狙って通信 ◦ hostname, zone, region をサポート ◦ Pod が無い場合に多段 Fallback も設定できる
  9. 21.

    EndpointSlice • Service に属する Endpoint を分割 ◦ Pod 100 個ごとに分割、部分的に更新可能

    ◦ 通信コストを下げることができる • Endpoint の改良版的な扱い ◦ Kubernetes v1.17 時点で β 機能 ◦ API が再設計されている ◦ Pod に対応する Topology の情報を保持
  10. 24.
  11. 25.
  12. 26.
  13. 27.
  14. 28.

    まとめ • マルチ AZ クラスタの留意点 ◦ AZ を跨いだ Pod 間通信のレイテンシの問題

    • Service Topology で通信を効率化 ◦ ネットワーク的に「近い」Pod を選択 • 背後にあるのは EndpointSlice ◦ 従来の Endpoint を分割・トポロジ情報を追加