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

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

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

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

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

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

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

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

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

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

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

複雑化していく MicroService

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

Conduit Overview Index > Overview Archtecture Features Roadmap

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

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

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)

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

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)

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

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)

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 -

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

Metrics monitor

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

$ 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

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

Linkerd Overview Index > Overview Archtecture Features Roadmap

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

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

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

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

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

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

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

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

Metrics monitor

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

Istio Overview Index > Overview Archtecture Features Roadmap

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

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

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

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

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

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

　　　Istio Metrics monitor

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

Istio Distributed Tracing

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

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

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

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)

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

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

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

Performance result

Performance result

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

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

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