Slide 1

Slide 1 text

Masaya Aoyama CyberAgent adtech studio ServiceMesh ͱ஥ؒͨͪ ʙIstio & Conduit & Linkerdʙ @Cloud Native Meetup Tokyo #1 MasayaAoyama @amsy810

Slide 2

Slide 2 text

連載「今こそ始めよう!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

Slide 3

Slide 3 text

Today’s Agenda 01 MicroService and ServiceMesh 02 Conduit Overview 03 Linkerd Overview 04 Istio Overview 05 Comparison and Performance Test

Slide 4

Slide 4 text

MicroService and ServiceMesh Index > What is Microservice Archtecture Benefit of Microservice Problem of MicroService and ServiceMesh

Slide 5

Slide 5 text

What is Microservice Archtecture? ProductPage Reviews Details Ra>ngs HTTP/gRPC HTTP/gRPC

Slide 6

Slide 6 text

Benefit of Micro Service マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成り立つ 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい

Slide 7

Slide 7 text

マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成り立つ 機能追加も比較的し易い スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Developer Benefit of Micro Service

Slide 8

Slide 8 text

マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成り立つ 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Micro Service

Slide 9

Slide 9 text

マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成り立つ 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Micro Service

Slide 10

Slide 10 text

マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成り立つ 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Micro Service

Slide 11

Slide 11 text

Nova presenta>on to DesignTuts team 11 Container is suitable for MicroService

Slide 12

Slide 12 text

複雑化していく MicroService

Slide 13

Slide 13 text

依存関係やデータフローの管理が困難 視覚的な 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 通信、サービス間認証、通信のブロック

Slide 14

Slide 14 text

Conduit Overview Index > Overview Archtecture Features Roadmap

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Micro Service Archtecture App a App b App c Deployment a Deployment b Deployment c Pod 各 Applica>on から 数珠つなぎで呼び出される

Slide 17

Slide 17 text

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)

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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)

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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)

Slide 22

Slide 22 text

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 -

Slide 23

Slide 23 text

Dashboard # Dashboard の起動 conduit dashboard 実体は kubectl port-forward + ブラウザ起動

Slide 24

Slide 24 text

Metrics monitor

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

$ 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

Slide 27

Slide 27 text

現状だと 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

Slide 28

Slide 28 text

Linkerd Overview Index > Overview Archtecture Features Roadmap

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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 に静的設定も可能

Slide 33

Slide 33 text

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 に書いておく

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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 形式を推奨

Slide 37

Slide 37 text

Metrics monitor

Slide 38

Slide 38 text

サポート(開発含む?)は続行するそうです @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

Slide 39

Slide 39 text

Istio Overview Index > Overview Archtecture Features Roadmap

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Micro Service Archtecture App a App b App c Deployment a Deployment b Deployment c Pod 各 Applica>on から 数珠つなぎで呼び出される

Slide 42

Slide 42 text

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 を構成する

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

   Istio Metrics monitor

Slide 47

Slide 47 text

Istio Service Graph Is>o が自動で検知して Service 間の依存関係を作成

Slide 48

Slide 48 text

Istio Distributed Tracing

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

ServiceMesh friends Istio & Conduit & Linkerd Index > Compare for catalog spec Compare for feature Performance test for mul>->er microservice Conclusions

Slide 52

Slide 52 text

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)

Slide 53

Slide 53 text

Is>o Conduit Linkerd Weekly Activity (last 32 weeks) ※ Adapted normalization

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Performance result

Slide 57

Slide 57 text

Performance result

Slide 58

Slide 58 text

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 の収集や可視化のみ

Slide 59

Slide 59 text

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 についてお話します。 運営に協力してくださる方 スポンサーしてくださる方も募集中です。

Slide 60

Slide 60 text

Do you have any questions? @amsy810 Thank you for your attention.