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

ServiceMesh と仲間たち 〜Istio & Conduit & Linkerd〜 @...

ServiceMesh と仲間たち 〜Istio & Conduit & Linkerd〜 @Cloud Native Meetup Tokyo #1

ServiceMesh と仲間たち 〜Istio & Conduit & Linkerd〜

様々な領域で話題になっている ServiceMesh。Istio、Conduit、Linkerd など、様々な選択肢がありますが、それぞれの特徴やできることについてまとめました。

@Cloud Native Meetup Tokyo #1

More Decks by Masaya Aoyama (@amsy810)

Other Decks in Technology

Transcript

  1. Masaya Aoyama CyberAgent adtech studio ServiceMesh ͱ஥ؒͨͪ ʙIstio & Conduit

    & Linkerdʙ @Cloud Native Meetup Tokyo #1 MasayaAoyama @amsy810
  2. 連載「今こそ始めよう!Kubernetes 入門」 @ThinkIT Japan Container Days v18.04 Keynote 登壇 CKA (CKA-1700-0138-0100)、CKAD

    (CKAD-1800-0002-0100) OpenStack Active Technical Contributor Masaya Aoyama (@amsy810) Infrastructure Engineer
  3. Today’s Agenda 01 MicroService and ServiceMesh 02 Conduit Overview 03

    Linkerd Overview 04 Istio Overview 05 Comparison and Performance Test
  4. MicroService and ServiceMesh Index > What is Microservice Archtecture Benefit

    of Microservice Problem of MicroService and ServiceMesh
  5. Benefit of Micro Service マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易

    小さい機能単位でデプロイが可能なため、高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成り立つ 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい
  6. 依存関係やデータフローの管理が困難 視覚的な Service Map レスポンスタイムやエラーレートの追跡 Latency、# of req、# of success

    等の可視化、分散トレーシング トラフィック制御が困難 Canary(Traffic ShiKing)、Rate Limit、Retry、Circuit Braker 障害試験が困難・影響範囲が不明 カオスエンジニアリング(hMp Fault、hMp Abort) ポリシーの管理が困難 Rate Limit、Retry 制御 MicroService の問題と ServiceMesh サービス間のセキュリティや認証 mTLS 通信、サービス間認証、通信のブロック
  7. Overview Authors of Linkerd 25+ Contributors Developers 2017-12 (0.1.0) Release

    0.4.1 (2018-04) Version 400+ Commits, 107 ksteps 1600+ Stars Commit Alpha Not yet for produc>on Adaption Light weight and promising Others
  8. Micro Service Archtecture App a App b App c Deployment

    a Deployment b Deployment c Pod 各 Applica>on から 数珠つなぎで呼び出される
  9. Archtecture public-api destination proxy-api conduit-proxy App a conduit-proxy App b

    conduit-proxy App c Deployment a Deployment b Deployment c Pod Data Plane Control Plane conduit-proxy (Rust) 全てのトラフィックを中継し Service Mesh を構成する tap (conduit-proxy)
  10. Archtecture public-api destination proxy-api conduit-proxy App a conduit-proxy App b

    conduit-proxy App c Deployment a Deployment b Deployment c Pod Data Plane Control Plane public-api CLI や Web から受ける API tap (conduit-proxy) CLI or Web
  11. Archtecture public-api destination proxy-api conduit-proxy App a conduit-proxy App b

    conduit-proxy App c Deployment a Deployment b Deployment c Pod Data Plane Control Plane des;na;on Service Discovery の情報を Proxy に提供する tap (conduit-proxy)
  12. Archtecture public-api destination proxy-api conduit-proxy App a conduit-proxy App b

    conduit-proxy App c Deployment a Deployment b Deployment c Pod Data Plane Control Plane proxy-api Proxy インスタンスからの要求を 受けて適切なコントローラへ tap (conduit-proxy) gRPC gRPC gRPC gRPC
  13. Archtecture public-api destination proxy-api conduit-proxy App a conduit-proxy App b

    conduit-proxy App c Deployment a Deployment b Deployment c Pod Data Plane Control Plane tap リクエストの Live Pipeline を提供 (後述) tap (conduit-proxy)
  14. How to use # Conduit Client の Install curl hMps://run.conduit.io/install

    | sh # CLI から Controll Plane の YAML を生成 conduit install | kubectl apply -f – # Control Plane のチェック # Kubernetes API の認証とバージョンをチェック conduit check # Demo App の起動(Conduit Proxy の Inject) curl hMps://raw.githubusercontent.com/runconduit/conduit-examples/master/emojivoto/emojivoto.yml \ | conduit inject - \ | kubectl apply -f -
  15. Simple stats $ conduit stat deployment -n emojivoto NAME MESHED

    SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 emoji 1/1 100.00% 2.0rps 1ms 1ms 1ms voting 1/1 81.36% 1.0rps 1ms 1ms 1ms web 1/1 90.83% 2.0rps 3ms 4ms 5ms $ conduit stat deploy/web --to deploy/voting -n emojivoto NAME MESHED SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 web 1/1 77.97% 1.0rps 1ms 2ms 2ms vo>ng web emoji
  16. $ conduit tap deploy/web --namespace emojivoto --path /leaderboard req id=0:50399

    src=10.240.0.23:61020 dst=10.20.5.9:80 :method=GET :authority=35.xxx.xxx.xxx :path=/leaderboard rsp id=0:50399 src=10.240.0.23:61020 dst=10.20.5.9:80 :status=200 latency=769µs end id=0:50399 src=10.240.0.23:61020 dst=10.20.5.9:80 duration=117µs response-length=560B …(ほぼリアルタイムでリクエストを識別可能) Realtime monitoring --max-rps float32 Maximum requests per second to tap. (default 1) --path string Display requests with paths that start with this prefix --scheme string Display requests with this scheme --method string Display requests with this HTTP method --namespace string Namespace of the specified resource (default "default") --to string Display requests to this resource --to-namespace string Sets the namespace used to lookup the "--to" resource Options
  17. 現状だと ServiceMesh の モニタリングツール状態 HA controller Roadmap Ref: hMps://conduit.io/roadmap/ Circuit

    Braker Retry policy Fault injec>on OpenTracing integra>on Mutual Authen>ca>on etc, Kubernetes Ingress Support
  18. Overview Buoyant, etc 71+ Contributors Developers 2016-01 (0.1.0) 2017-04 (1.0.0)

    Release 1.4.0 (2018-05) Version 1200+ Commits, 172 ksteps 4500+ Stars Commit TwiMer, Pinterest, Tumblr, PagerDuty for produc>on Adaption 5th CNCF Project Others
  19. Deployment a Deployment b Deployment c App c App b

    App a App c App b App a App c App b App a Node A Node B Node C 各 Applica>on から 数珠つなぎで呼び出される Micro Service Archtecture
  20. Archtecture (per Host) l5d l5d l5d Deployment a Deployment b

    Deployment c Data Plane Control Plane l5d (Scala) 全てのトラフィックを中継し Service Mesh を構成する App c App b App a App c App b App a App c App b App a Node A Node B Node C namerd
  21. Archtecture (per Host) l5d l5d l5d Deployment a Deployment b

    Deployment c Data Plane Control Plane App c App b App a App c App b App a App c App b App a Node A Node B Node C namerd namerd Dtabs のリストを管理 使用せず l5d に静的設定も可能
  22. namerd traffic control Request [GET foo.com] Service Name [/srv/foo.com] Client

    Name [/#/io.l5d.k8d/default/http/world-v1] Replicas [1.1.1.1:80, 1.1.1.2:80] Identification  論理名への変換 Identifier Binding  具体名への変換 dtab (Delegation Table) Resolution  物理エンドポイントへの変換 namer 静的な Config を Linkerd に書いておく
  23. namerd traffic control Request [GET foo.com] Service Name [/srv/foo.com] Client

    Name [/#/io.l5d.k8d/default/http/world-v1] Replicas [1.1.1.1:80, 1.1.1.2:80] Identification  論理名への変換 Identifier Binding  具体名への変換 dtab (Delegation Table) Resolution  物理エンドポイントへの変換 namer namerd Etcd, Zookeeper Dtab の中央管理により 動的な Traffic control
  24. namerd traffic control Request [GET foo.com] Service Name [/srv/foo.com] Client

    Name [/#/io.l5d.k8d/default/http/world-v1] (99%) or [/#/io.l5d.k8d/default/http/world-v2] (1%) Replicas [1.1.1.1:80, 1.1.1.2:80] (99%) or [2.2.2.1:80, 2.2.2.2:80] (1%) $ namerctl dtab update … /host/foo.com=> 99 * /srv/world-v1 & 1 * /srv/world-v2 … Identification  論理名への変換 Identifier Binding  具体名への変換 dtab (Delegation Table) Resolution  物理エンドポイントへの変換 namer namerd Etcd, Zookeeper Dtab の中央管理により 動的な Traffic control Update
  25. Archtecture (per Pod) namerd l5d App a l5d App b

    l5d App c Deployment a Deployment b Deployment c Pod Data Plane Control Plane l5d が重めのプロセスなため、 per Host 形式を推奨
  26. サポート(開発含む?)は続行するそうです @KubeCon + CloudNa>veCon 2017 NorthAmerica Keynote Roadmap and difference

    with Mul> plaporm vs Kubernetes Specific Feature-rich vs lightweight Maximum config vs Minimum config per Host proxy vs per Pod proxy
  27. Istio Overview Google, IBM, LyK, etc. 178+ Contributors Developers 2017-05

    (0.1.0) Release 0.7.1 (2018-03) Version 4300+ Commits, 735 ksteps 7900+ Stars Commit Beta – Alpha Not yet for produc>on Adaption Maybe most famous Others
  28. Micro Service Archtecture App a App b App c Deployment

    a Deployment b Deployment c Pod 各 Applica>on から 数珠つなぎで呼び出される
  29. Istio Archtecture Pilot Mixer Istio-Auth Envoy App a Envoy App

    b Envoy App c Deployment a Deployment b Deployment c Pod Data Plane Control Plane Envoy (C++) 全てのトラフィックを中継し Service Mesh を構成する
  30. Pilot Mixer Istio-Auth Data Plane Control Plane Envoy App a

    Envoy App b Envoy App c Deployment a Deployment b Deployment c Pod Pilot Service Discovery の結果を元に Envoy 設定の動的更新を行う Istio Archtecture
  31. Pilot Mixer Istio-Auth Data Plane Control Plane Envoy App a

    Envoy App b Envoy App c Deployment a Deployment b Deployment c Pod Mixer メトリクスの収集 Quota や Policy のチェック Istio Archtecture
  32. Pilot Mixer Istio-Auth Data Plane Control Plane Envoy App a

    Envoy App b Envoy App c Deployment a Deployment b Deployment c Pod Is;o-Auth SA ベースの認証機能の提供 mTLS の提供 Istio Archtecture mTLS mTLS
  33. Performance up V0.5.0 > v0.7.1 (~= 2 month) Throughput: +142%

    (total: 242%) Latency (p50): -59% Is;o mesh expansion Join VM and baremetal to Kubernetes is>o mesh Controller reachable and w/o NATS,FW Fine-grained Access Control and Audi;ng AMribute and role-based access controll, etc Is;o mul; cluster expansion Join K8s is>o mesh and K8s is>o mesh Is>o controller installed on one side Istio Roadmap & latest action Node Node Node VM or Metal Node Node Node Node Node Node
  34. Performance up V0.5.0 > v0.7.1 (~= 2 month) Throughput: +142%

    (total: 242%) Latency (p50): -59% Is;o mesh expansion Join VM and baremetal to Kubernetes is>o mesh Controller reachable and w/o NATS,FW Fine-grained Access Control and Audi;ng AMribute and role-based access controll, etc Is;o mul; cluster expansion Join K8s is>o mesh and K8s is>o mesh Is>o controller installed on one side Istio Roadmap & latest action Node Node Node VM or Metal Node Node Node Node Node Node
  35. ServiceMesh friends Istio & Conduit & Linkerd Index > Compare

    for catalog spec Compare for feature Performance test for mul>->er microservice Conclusions
  36. Compare for catalog spec    Is;o For produc>on Beta - Alpha

    Alpha GA Contributors 178+ 25+ 71+ Commits 4300+ 400+ 1200+ Stars 7900+ 1600+ 4500+ Codes 735 ksteps 107 ksteps 172 ksteps Released at 2017-05 2017-12 2016-01 (GA: 2017-04) Latest version 0.7.1 0.4.1 1.4.0 Base technology Envoy (C++) ConduitProxy (Rust) Linkerd (Scala) Configra>on Method CRD (K8s resource) Conduit CLI? namerctl (CLI)
  37. Compare for feature    Is;o Zero configura>on ◯ △(manual inject) ☓

    Visualize ServiceMap ◯ ☓ ☓ Traffic shiKing ◯ ☓ ◯ Rate Limit ◯ ☓ ☓ Retry ◯ ☓ ◯ Circuit Braker ◯ ☓ ◯ Latency Metrics ◯ ◯ ◯ # of Request Metrics ◯ ◯ ◯ # of Success Metrics ◯ ◯ ◯ Fault Injec>on ◯ ☓ ☓ mTLS ◯ ☓ ◯ Distributed tracing ◯ ☓ ◯ etc… good - good
  38. Tier Performance Test App a App b App c Deployment

    a Deployment b Deployment c Pod CPU: Intel Xeon E5 2.2GHz (Broadwell) Kubernetes: 1.9.7-gke.0 Node: n1-starndard-8 (vCPU: 8, Memory 30 GB) * 3 Deployment: nginx:1.13 * 6 pods * 5 deployments (5-;er) ServiceMesh: Latest version Is>o na>ve vs vs
  39. Conclusion Istio まだ Alpha リリース アプリ側の改修が不要 後発なので機能的に不足が多い Conduit CLI で管理

    シンプル Tap でのリアルタイムデバッグが良い Linkerd の知見を生かしている Sidecar パターンより daemonset を推奨 宛先トラフィックを host に向ける必要 があるためアプリ側に設定が必要 わりと複雑 Is>o with Linkerd 構成も可能 既に GA リリース 利用実績も多い(銀行、TwiMer、etc) Namerctl CLI で管理 まだ Beta - Alpha リリース 一番注目度が高いため活発 CRD (YAML) で管理出来る 機能的にはかなり揃ってきている Sidecar を AutoInject するため ほぼ意識する必要がない 現状は Metrics の収集や可視化のみ
  40. Cloud Native に近しい技術や CNCF がホストするプロジェクトについて共有し合う会です! 昨今はコンテナ関係のエコシステムが大量に増えてきましたが、 それらの技術検証結果などを発表しあう場として利用していきたいと思っており、仲間を募集しております。 1. Skaffold で

    Kubernetes ネイティブ な開発環境を作ってみた Skaffoldは、コンテナのビルド、プッシュ、k8sへのデプ ロイを自動化して、開発作業をを効率化してくれるCLI ツールです。今回、Skaffoldの利用方法を解説するとと もに、ローカル開発、CI/CDへの組み込みで使ってみた ので、実際の使用感をレポートします。 2. コンテナネイティブな ワークフローエンジン Argo Kubernetes 上に展開できるコンテナネイティブなワー クフローエンジン Argo。ワークフローを Custom Resource Definition で定義することができるため、親 和性の高い YAML で管理することが可能です。今回は Argo で出来ることや、今後注力していくCI/CDなどの 機能についてお話します。 3. Introduction to Kubeflow 0.1 and future KubeCon 2017 NA で発表、KubeCon 2018 EU で 0.1 のリリースが報告された ML 環境を Kubernetes 上で提供する Kubeflow。Kubernetes での ML ワー クフローの展開を「シンプル」「ポータブル」「スケーラブ ル」にするために開発されています。今回は KubeCon 2018 EU での発表を交えながら、ML 関連の検証プロ ジェクトで検証中の Kubeflow についてお話します。 運営に協力してくださる方 スポンサーしてくださる方も募集中です。