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

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
Ratings
HTTP/gRPC HTTP/gRPC

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

い
機能追加も比較的し易い
Developer
Benefit of
Micro Service

い
機能追加も比較的しやすい
Benefit of
Micro Service

NovapresentationtoDesignTutsteam
11
Container is suitable
for MicroService

複雑化していく MicroService

依存関係やデータフローの管理が困難
視覚的な Service Map
レスポンスタイムやエラーレートの追跡
Latency、# of req、# of success 等の可視化、分散トレーシ
ング
トラフィック制御が困難
Canary（Traffic Shifting）、Rate Limit、Retry、Circuit Braker
障害試験が困難・影響範囲が不明
カオスエンジニアリング（http Fault、http 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 production
Adaption
Light weight and promising
Others

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

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

Archtecture
conduit-proxy
App a
conduit-proxy
App b
conduit-proxy
App c
Pod
public-api
CLI や Web から受ける API
tap (conduit-proxy)
CLI or Web

Archtecture
conduit-proxy
App a
conduit-proxy
App b
conduit-proxy
App c
Pod
destination
Service Discovery の情報を
Proxy に提供するtap (conduit-proxy)

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

Archtecture
conduit-proxy
App a
conduit-proxy
App b
conduit-proxy
App c
Pod
tap
リクエストの Live Pipeline を提
供
（後述）tap (conduit-proxy)

How to use
# Conduit Client の Install
curl https://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 https://raw.githubusercontent.com/runconduit/conduit-examples/master/emojivoto/emojivoto.yml
| conduit inject -
| kubectl apply -f -

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

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
voting 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: https://conduit.io/roadmap/
Circuit Braker
Retry policy
Fault injection
OpenTracing integration
Mutual Authentication
etc,
Kubernetes Ingress Support

Linkerd OverviewIndex >
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
4500+ Stars
Commit
Twitter, Pinterest, Tumblr,
PagerDuty for production
Adaption
5th CNCF Project
Others

Deployment a
Deployment b
Deployment cApp c
App b
App a
App c
App b
App a
App c
App b
App a
Node A Node B Node C
各 Application から
数珠つなぎで呼び出される
Micro Service Archtecture

Archtecture (per Host)
l5d l5d l5d
Deployment a
Deployment b
Deployment c
l5d (Scala)
Service Mesh を構成する
App c
App b
App a
App c
App b
App a
App c
App b
App a
namerd

Archtecture (per Host)
l5d l5d l5d
Deployment a
Deployment b
Deployment c
App c
App b
App a
App c
App b
App a
App c
App b
App a
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 に書いておく

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
Resolution
換
namer
namerd
Etcd,
Zookeeper
Dtab の中央管理により
動的な 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
Resolution
換
namer
namerd
Etcd,
Zookeeper
Dtab の中央管理により
動的な Traffic control
Update

Archtecture (per Pod)
namerd
l5d
App a
l5d
App b
l5d
App c
Pod
l5d が重めのプロセスなため、
per Host 形式を推奨

サポート（開発含む？）は続行するそうです
@KubeCon + CloudNativeCon 2017 NorthAmerica Keynote
Roadmap and difference with
Multi platform vs Kubernetes Specific
Feature-rich vs lightweight
Maximum config vs Minimum config
per Host proxy vs per Pod proxy

Index >
Overview
Archtecture
Features
Roadmap

Istio Overview
Google, IBM, Lyft, etc.
178+ Contributors
Developers
2017-05 (0.1.0)
Release
0.7.1 (2018-03)
Version
7900+ Stars
Commit
Beta – Alpha
Not yet for production
Adaption
Maybe most famous
Others

Istio Archtecture
Pilot Mixer Istio-Auth
Envoy
App a
Envoy
App b
Envoy
App c
Pod
Data Plane
Control Plane
Envoy (C++)
Service Mesh を構成する

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

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

Data Plane
Control Plane
Envoy
App a
Envoy
App b
Envoy
App c
Pod
Istio-Auth
SA ベースの認証機能の提供
mTLS の提供
Istio Archtecture
mTLS mTLS

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

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

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

Compare for catalog spec
Istio
For production 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)
Configration Method CRD (K8s resource) Conduit CLI? namerctl (CLI)

Istio
Conduit
Linkerd
Weekly Activity (last 32 weeks)
※ Adapted normalization

Compare for feature
Istio
Zero configuration ◯ △(manual inject) ☓
Visualize ServiceMap ◯ ☓ ☓
Traffic shifting ◯ ☓ ◯
Rate Limit ◯ ☓ ☓
Retry ◯ ☓ ◯
Circuit Braker ◯ ☓ ◯
Latency Metrics ◯ ◯ ◯
# of Request Metrics ◯ ◯ ◯
# of Success Metrics ◯ ◯ ◯
Fault Injection ◯ ☓ ☓
mTLS ◯ ☓ ◯
Distributed tracing ◯ ☓ ◯
etc… good - good

Tier Performance Test
App a App b App 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-tier)
ServiceMesh: Latest version
Istio
native
vs
vs

Conclusion
Istio
まだ Alpha リリース
アプリ側の改修が不要
後発なので機能的に不足が多い
Conduit CLI で管理
シンプル
Tap でのリアルタイムデバッグが良
い
Linkerd の知見を生かしている
Sidecar パターンより daemonset を推
奨
宛先トラフィックを host に向ける必
要があるためアプリ側に設定が必要
わりと複雑
Istio with Linkerd 構成も可能
既に GA リリース
利用実績も多い（銀行、Twitter、
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.

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

Similar to ServiceMesh と仲間たち〜Istio & Conduit & Linkerd〜 @Cloud Native Meetup Tokyo #1 (20)

More from Masaya Aoyama

More from Masaya Aoyama (12)