Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Istio⛵️によるサービスディスカバリーの仕組み

 Istio⛵️によるサービスディスカバリーの仕組み

Istioのサービスディスカバリーの仕組みについて、Envoyを交えながら解説しました。

もう少し詳しく知りたい方は、こちらのブログ投稿をご参照ください:
https://hiroki-hasegawa.hatenablog.jp/entry/2022/12/25/060000

登壇イベント:
https://3-shake.connpass.com/event/267080/

More Decks by Hiroki Hasegawa (長谷川広樹)

Other Decks in Programming

Transcript

  1. Istio⛵による サービスディスカバリーの仕組み 株式会社スリーシェイク 長谷川広樹 github.com/hiroki-it @Hiroki__IT 2022/12/15 3-shake SRE Tech

    Talk
  2. スライドが多く やや駆け足の発表になります󰢙

  3. 自己紹介 ▼ お仕事 マイクロサービスアーキテクチャのインフラ領域 Kubernetes、Istio、ArgoCD、Terraform、... ▼ 大好きな技術領域 ・マイクロサービスアーキテクチャ ・サービスメッシュ ・DDD

    github.com/hiroki-it @Hiroki__IT 長谷川 広樹 (はせがわ ひろき) 株式会社スリーシェイク
  4. 目次 ▪ はじめに ▪ Istio⛵によるサービスディスカバリー (以降 SD) の仕組み ▪ EnvoyがADS-APIから取得した値を見てみよう

    ▪ おわりに
  5. はじめに

  6. マイクロサービスアーキテクチャにおけるSDとは 宛先マイクロサービスを検出し 送信元マイクロサービスが宛先と通信できるようにする

  7. なぜSDが必要なのか 宛先マイクロサービスのインスタンスは スケーリングで増減するたびに ネットワーク上の宛先を変化させる 宛先をその都度検出し 送信元マイクロサービスが 宛先と継続的に通信できる必要性

  8. SDの要素 要素 責務 送信元マイクロサービス リクエストを送信 宛先マイクロサービス リクエストを受信 サービスレジストリ 宛先マイクロサービスの宛先情報を保管 ロードバランサー

    宛先マイクロサービスのインスタンスにロードバランシング 名前解決 DNSベースのSDで使用するため、IstioのSDでは扱わない
  9. Istio⛵による SDの仕組み

  10. IstioによるSDの仕組み Podに自動注入される istio-proxyコンテナが軸 1. kube-apiserverがPod等の宛先情報を etcdなどに保管 (これはK8sの通常の仕組み) 2. discoveryはkube-apiserverから Pod等の宛先情報を取得して保管

    3. istio-proxyはdiscoveryから Pod等の宛先情報を取得 4. 送信元マイクロサービスが 宛先マイクロサービスにリクエストを送信し iptablesがistio-proxyにリダイレクト 5. istio-proxy内でロードバランシングされ 宛先Podにリクエストを送信
  11. (あなたの心の声が聞こえます) istio-proxy 詳しく知りたいなぁ...😒

  12. IstioによるSDの仕組み istio-proxyを少し詳しく... 1. kube-apiserverがPod等の宛先情報を etcdなどに保管 (これはK8sの通常の仕組み) 2. discoveryはkube-apiserverから Pod等の宛先情報を取得してメモリ上に保管 3.

    istio-proxy内のEnvoyはpilot-agentを介して discoveryのADS-APIからPod等の宛先情報を取得 4. 送信元マイクロサービスが 宛先マイクロサービスにリクエストを送信し iptablesがistio-proxyにリダイレクト 5. istio-proxy内のEnvoyは 宛先Podにリクエストをロードバラシング
  13. (あなたの心の声が聞こえます) Envoyが取得した宛先情報 見てみたいなぁ...😒

  14. Envoyが ADS-APIから取得した情報を 見てみよう

  15. EnvoyがADS-APIから取得した情報を見てみよう $ kubectl exec \ -it foo-pod \ -n foo-namespace

    \ -c istio-proxy \ -- bash -c "curl http://localhost:15000/config_dump" | yq -P 実際にEnvoyに登録されている宛先情報は istio-proxyの localhost:15000/config_dump からJSONで取得可能 JSONだと見にくいので、yqコマンドでYAMLに変換するとよい フォントサイズの制約上『中略』が多くなっています󰣹 お手元のIstioで、後ほどEnvoyをじっくり冒険していただけると
  16. Envoyの処理の流れ リスナー ⇨ ルート ⇨ クラスター ⇨ エンドポイント 確認できた設定値を、Envoyの処理の流れ󰗅に当てはめていく...

  17. リスナー値 istio-proxyがADS-APIから取得したリスナー値は /config_dump?resource={dynamic_listeners} から確認できる $ kubectl exec \ -it foo-pod

    \ -n foo-namespace \ -c istio-proxy \ -- bash -c "curl http://localhost:15000/config_dump?resource={dynamic_listeners}" | yq -P ここでは foo-pod内でbar-podのリスナー値を 確認したとする
  18. "configs": - "@type": type.googleapis.com/envoy.admin.v3.ListenersConfigDump.DynamicListener name: 0.0.0.0_50002 # リスナー名 active_state: listener:

    "@type": type.googleapis.com/envoy.config.listener.v3.Listener name: 0.0.0.0_50002 address: socket_address: address: 0.0.0.0 # 受信したパケットのうちで、宛先 IPアドレスでフィルタリング port_value: 50002 # 受信したパケットのうちで、宛先ポート番号でフィルタリング filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager rds: route_config_name: 50002 # 本リスナーに紐づくルート名 ... 中略 - "@type": type.googleapis.com/envoy.admin.v3.ListenersConfigDump.DynamicListener ... 中略
  19. ルート値 $ kubectl exec \ -it foo-pod \ -n foo-namespace

    \ -c istio-proxy \ -- bash -c "curl http://localhost:15000/config_dump?resource={dynamic_route_configs}" | yq -P istio-proxyがADS-APIから取得したルート値は /config_dump?resource={dynamic_route_configs} から確認できる ここでは foo-pod内でbar-podのルート値を 確認したとする
  20. configs: - "@type": type.googleapis.com/envoy.admin.v3.RoutesConfigDump.DynamicRouteConfig route_config: "@type": type.googleapis.com/envoy.config.route.v3.RouteConfiguration name: 50002 #

    ルート名 virtual_hosts: - name: bar-service.bar-namespace.svc.cluster.local:50002 domains: - bar-service.bar-namespace.svc.cluster.local # ホストベースルーティング ... 中略 routes: - match: prefix: / # パスベースルーティング route: cluster: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local # 本ルートに紐づくクラスター名 ... 中略 - '@type': type.googleapis.com/envoy.admin.v3.RoutesConfigDump.DynamicRouteConfig ... 中略
  21. クラスター値 $ kubectl exec \ -it foo-pod \ -n foo-namespace

    \ -c istio-proxy \ -- bash -c "curl http://localhost:15000/config_dump?resource={dynamic_active_clusters}" | yq -P istio-proxyがADS-APIから取得したクラスター値は /config_dump?resource={dynamic_active_clusters} から確認できる ここでは foo-pod内でbar-podのクラスター値を 確認したとする
  22. "configs": - "@type": type.googleapis.com/envoy.admin.v3.ClustersConfigDump.DynamicCluster cluster: "@type": type.googleapis.com/envoy.config.cluster.v3.Cluster name: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local #

    クラスター名 type: EDS eds_cluster_config: eds_config: ads: {} initial_fetch_timeout: 0s resource_api_version: V3 # クラスターに紐づくエンドポイントの親名 service_name: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local ... 中略 - "@type": type.googleapis.com/envoy.admin.v3.ClustersConfigDump.DynamicCluster ... 中略
  23. エンドポイント値 ここでは foo-pod内でbar-podのエンドポイント値を 確認したとする $ kubectl exec \ -it foo-pod

    \ -n foo-namespace \ -c istio-proxy \ -- bash -c "curl http://localhost:15000/config_dump?include_eds" | yq -P istio-proxyがADS-APIから取得したエンドポイント値は /config_dump?include_eds から確認できる
  24. configs: dynamic_endpoint_configs: - endpoint_config: "@type": type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignment cluster_name: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local # エンドポイントの親名を指定している。

    endpoints: - lb_endpoints: - endpoint: address: socket_address: address: 11.0.0.1 # 冗長化されたbar-podのIPアドレス port_value: 80 # bar-pod内のコンテナが待ち受けているポート番号 ... 中略 - endpoint: address: socket_address: address: 11.0.0.2 # 冗長化されたbar-podのIPアドレス port_value: 80 # bar-pod内のコンテナが待ち受けているポート番号 ... 中略 - endpoint_config: ... 中略
  25. まとめ:EnvoyがADS-APIから取得した値 送信元マイクロサービスが “<任意のIP>/:50002” 宛てのリクエストを送信した場合 0.0.0.0_50002 リスナーで受信し bar-pod (11.0.0.X/:80) にロードバランシング

  26. おわりに

  27. Istio⛵ ありがとう!!

  28. 参考文献 ▼ マイクロサービスアーキテクチャのSD ・https://microservices.io/patterns/server-side-discovery.html ・https://www.amazon.co.jp/dp/B09782D5HZ ・https://www.baeldung.com/cs/service-discovery-microservices ▼ Istioによるサービスディスカバリーの仕組み ・https://www.amazon.co.jp/dp/1617295825 ・https://www.amazon.co.jp/dp/1492043788

    ・https://www.zhaohuabing.com/categories/tech/ ・https://jimmysong.io/categories/istio/ ▼ Envoyの処理の流れ ・https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request ・https://www.alibabacloud.com/blog/architecture-analysis-of-istio-the-most-popular-service-mesh-project_597010 ▼ アイコン ・https://kubernetes.io/ ・https://istio.io/latest/ ・https://cncf-branding.netlify.app/projects/envoy/