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

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

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

@Cloud Native Meetup Tokyo #1

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. What is Microservice Archtecture? ProductPage Reviews Details Ra>ngs HTTP/gRPC HTTP/gRPC
6. Benefit of Micro Service マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成り立つ 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい
7. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成り立つ 機能追加も比較的し易い スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Developer Benefit of Micro Service
8. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成り立つ 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Micro Service
9. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成り立つ 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Micro Service
10. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成り立つ 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Micro Service
11. Nova presenta>on to DesignTuts team 11 Container is suitable for MicroService
12. 複雑化していく MicroService
13. 依存関係やデータフローの管理が困難 視覚的な 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 通信、サービス間認証、通信のブロック
14. Conduit Overview Index > Overview Archtecture Features Roadmap
15. 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
16. Micro Service Archtecture App a App b App c Deployment a Deployment b Deployment c Pod 各 Applica>on から 数珠つなぎで呼び出される
17. 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)
18. 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
19. 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)
20. 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
21. 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)
22. 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 -
23. Dashboard # Dashboard の起動 conduit dashboard 実体は kubectl port-forward + ブラウザ起動
24. Metrics monitor
25. 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
26. $ 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
27. 現状だと 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
28. Linkerd Overview Index > Overview Archtecture Features Roadmap
29. 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
30. 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
31. 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
32. 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 に静的設定も可能
33. 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 に書いておく
34. 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
35. 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
36. 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 形式を推奨
37. Metrics monitor
38. サポート（開発含む？）は続行するそうです @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
39. Istio Overview Index > Overview Archtecture Features Roadmap
40. 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
41. Micro Service Archtecture App a App b App c Deployment a Deployment b Deployment c Pod 各 Applica>on から 数珠つなぎで呼び出される
42. 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 を構成する
43. 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
44. 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
45. 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
46. 　　　Istio Metrics monitor
47. Istio Service Graph Is>o が自動で検知して Service 間の依存関係を作成
48. Istio Distributed Tracing
49. 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
50. 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
51. ServiceMesh friends Istio & Conduit & Linkerd Index > Compare for catalog spec Compare for feature Performance test for mul>->er microservice Conclusions
52. 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)
53. Is>o Conduit Linkerd Weekly Activity (last 32 weeks) ※ Adapted normalization
54. 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
55. 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
56. Performance result
57. Performance result
58. 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 の収集や可視化のみ
59. 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 についてお話します。 運営に協力してくださる方 スポンサーしてくださる方も募集中です。
60. Do you have any questions? @amsy810 Thank you for your attention.