Istio Overview

© Hitachi, Ltd. 2020. All rights reserved.
Istio Overview
#gcpug
株式会社⽇⽴製作所
研究開発グループ
井出貴也
- GCPUG Tokyo Istio 1.5 Day -

View Slide

本セッションの趣旨
§ 初⼼者の⽅を対象にService Meshの背景や
Istioのユースケースをご紹介します
§ また，時間があれば⽇⽴でのIstio運⽤を通して得た
気付きや提案中の機能をご紹介します
§ ⽇⽴事例の詳細は下記をご参照下さい
1
@IT, マイクロサービスを⽀える「Istio」の実⼒は？
サービスメッシュの利点と課題
SpeakersDeck, 1年間のシステム運⽤を通して
分かったIstioの嬉しさと活⽤における注意点

View Slide

内容
1. なぜService Meshが求められるのか?
2. Istioとは?
3. Istioのユースケースと機能
4. Istio活⽤に向けた⽇⽴での取り組み
2

View Slide

なぜService Meshが求められるのか
3

View Slide

Microservice
§ 複数の⼩さなサービスを連携させてシステムを構成する設計⼿法
§ サービスごとに⼩さなチームが存在。⾃律的に開発・運⽤
§ 利点
◇ ⼤規模開発しやすい
◇ 変更しやすい
◇ スケーリングしやすい
◇ 障害が波及しにくい
4
Microservice
UI
Auth
Svc1
Svc2
Svc3

View Slide

Microserviceの成⻑
§ ビジネスの成⻑に伴いシステムは⼤きくなる
◇ サービスやサービスチームの増加
◇ それぞれのサービスが随時変化していく
◇ サービスの開発⾔語や品質も様々
5
※イメージ図

View Slide

Microserviceの運⽤
Microserviceをどのように運⽤するか？
◇ サービス間のルーティングは？
◇ 宛先のサービスが落ちていた場合は？
◇ 通信のアクセス制御は？
◇ システム全体の可視化は？
6

View Slide

Microservice運⽤⽅法の模索
§ 各サービスチームが課題を個別解決 →
◇ 開発・運⽤の⼯数が⼤きい
◇ 仕様や品質がバラバラになる
◇ 分散トレーシングなどはチーム内で閉じない
§ 共通機能をライブラリ化し各チームに提供 →
◇ ライブラリ導⼊にサービスの改修が必要
◇ サービスのライフサイクルがライブラリに縛られる
7
各サービスから透過的で, システム全体に渡って⼀貫性のある解決⽅法が必要

View Slide

Service Meshというアイデア
8
各サービスから透過的で, システム全体に渡って⼀貫性のある解決⽅法が必要
各サービスの前段にProxyを配置し, そのProxyをControl Planeで⼀元管理する
どのように実現するのか

View Slide

Service Meshの仕組み
§ 各サービスへの通信の端点を
プロキシが抑えている
§ プロキシを操作することにより
サービス間通信を⾃由に制御
◇ Routing, Splitting
◇ Access Control
◇ Monitoring, etc.
9
UI
Auth
Svc1
Svc2
Svc3
Proxy
Proxy
Proxy
Proxy
Proxy
Control
各サービスの前段にプロキシを配置し,
そのプロキシをコントロールプレーンで⼀元管理するインフラレイヤ
各サービスの前段にProxyを配置し,
そのProxyをControl Planeで⼀元管理するインフラレイヤ
Service Mesh
Control
Plane Control

View Slide

© Hitachi, Ltd. 2020. All rights reserved. 10
Istio

View Slide

Istioとは？
11

View Slide

Istio Overview
12
https://github.com/istio/istio
§ GoogleとIBMが主導するOSSのService Mesh
§ ⾼機能, ⾼い知名度
◇ ⽐較: INNOQ Service Mesh Comparison
◇ GitHub Fastest Growing Project 第4位
§ Kubernetes上で動作
◇ マネージドサービスも存在
ü GKE addon
ü Anthos Service Mesh
Istio

View Slide

§ Control Planeはistio-system Namespace内に保持
§ Proxyは各Podの内部にサイドカーとしてデプロイ(auto-injection可能)
◇ iptablesが修正され, Proxyを中継してContainerに通信が届く
Istioのアーキテクチャ
13
Kubernetes
istio-system NameSpace your_app Namespace
Pod
Pod
Container Container
Service
Service
Proxy Proxy
Control
Plane

View Slide

14
Kubernetes
Pod
Pod
Container Container
Service
Service
Proxy Proxy
Control
Plane

View Slide

Istio Control Plane (〜v1.4)
Mixer
§ メトリクス収集
§ Policyチェック
Pilot
§ プロキシへの設定デリバリ
§ Service Discovery
Citadel
§ TLSの鍵管理
Galley
§ 基盤システム(k8s)連携
15
https://archive.istio.io/v1.4/docs/ops/deployment/architecture/

View Slide

Istio Control Plane (v1.5〜)
Istiod
§ プロキシへの設定配布
§ TLSの鍵管理
§ 基盤システム(k8s)連携
§ サービスへのプロキシ挿⼊など
§ 従来のPilot, Citadel, Galley,
Webhook Injector,
Pilot agent の機能が集約
※MixerはProxy側に移動
16
https://istio.io/docs/ops/deployment/architecture/

View Slide

17
Kubernetes
Pod
Pod
Container Container
Service
Service
Proxy Proxy
Control
Plane

View Slide

Envoy Proxy
§ Lyftが開発したL4/L7プロキシ
§ API経由での無停⽌設定変更
§ 多機能
§ 本番サービスでの利⽤実績
§ 多くのService Meshがプロキシ
として採⽤
https://github.com/Proxyproxy/artwork 18

View Slide

Istio導⼊の判断
§ ユースケースがあるか
◇ 複数のサービスに対し, ⼀貫性のある通信管理を⾏いたいのか
◇ それはIstioの運⽤負荷を超えるメリットがあるのか
§ 運⽤できるか
◇ システムの複雑化を許容できるか
◇ リソース消費量の増加が許容できるか
◇ レイテンシ追加を許容できるか
◇ 運⽤体制はあるか
§ When You Do (and Don’t Need) a Service Mesh - THE NEW STACK
◇ https://thenewstack.io/when-you-do-and-dont-need-a-service-mesh/
19

View Slide

Istioのユースケースと機能
20

View Slide

Istioのユースケース
Istio By Example
https://istiobyexample.dev/
§ ユースケースごとに機能解説と
マニフェストのサンプルが掲載
§ 作成者はGoogleのMeganさん
§ Meganさんに翻訳許可を
いただいたため，和訳予定
21
下記サイトから抜粋

View Slide

Istioの機能
22
Traffic Management Security Management
Observability
Routing, Mirroring, Splitting,
Rate Limit, Timeout, Retry,
CORS, Fault Injection, etc.
Mutual TLS,
End User Authorization,
Authentication
Monitoring, Logging,
Distributed Tracing
よく挙げられる機能3種
私的にはもう⼀種存在

View Slide

Istioの機能
23
Traffic Management Security Management
Observability Cluster Expansion
Routing, Mirroring, Splitting,
Rate Limit, Timeout, Retry,
CORS, Fault Injection, etc.
Mutual TLS,
End User Authorization,
Authentication
Monitoring, Logging,
Distributed Tracing
Multiple Kubernetes
Cluster, VM Expansion

View Slide

Traffic Management
§ ルーティング
◇ ポリシーに基づく動的な通信制御
◇ Kubernetes情報(Namespace, Label,...)や
トラヒック情報(URI, HTTP Header,...)を⽤いた指定が可能
§ 通信制御
◇ トラヒックの複製や分岐，レート設定が可能
◇ Canary ReleaseやAB testは本機能で実現
§ アプリレベルの制御
◇ 通信のタイムアウトやリトライ，サーキットブレイクなど
◇ URIやHTTP Headerの修正も可能
24

View Slide

ユースケース: Path-based Routing
URIのパスでルーティングを⾏う
§ myappサービス宛の通信であっても,
/login はauthサービスにリクエスト送付
§ これはシンプルな例。ここにトラヒック分岐や
リトライ制御, HTTP Header/URIの修正など
を組み合わせられる
https://istiobyexample.dev/path-based-routing/
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: auth-redirect
spec:
hosts:
- myapp
http:
- match:
- uri:
prefix: "/login"
route:
- destination:
host: auth
- route:
- destination:
host: myapp
25

View Slide

ユースケース: Ingress
クラスタ外からの通信を受け付ける
§ 外部からの通信をGatewayリソースでメッ
シュ内に引き⼊れるイメージ
https://istiobyexample.dev/ingress/ 26
kind: Gateway
metadata:
name: hello-gateway
spec:
selector:
istio: ingressgateway # use default
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "hello.com"
---
kind: VirtualService
...
spec:
hosts:
- "hello.com"
gateways:
- hello-gateway
http:
- route:
- destination:
host: hello.default.svc.cluster.local
port:
number: 80
名前設定
GWを指定
§ Gatewayリソースで
IngressGatewayを
制御
§ IngressGatewayを
経由した通信は
gatewaysを指定した
VirtualServiceにて
制御

View Slide

Security and Policy
§ サービス間認証
◇ Pod間の認証。mTLSにより送信側と受信側双⽅が証明書で互いを認証
◇ Auto mTLSによりIstio配下のPodは⾃動でmTLSが適⽤される(v1.5~)
§ エンドユーザ認証
◇ JSON Web Tokenを⽤いた認証
◇ istio-1.5でRequestAuthenticationリソースが追加された
§ 認可
◇ L7レベルのアクセス制御を⾏う
◇ k8sの情報とトラフィックの情報が利⽤できる
27

View Slide

ユースケース: Authorization(認証)
k8s情報と通信情報を⽤いたアクセス制御
§ ServiceAccountがinventory-saのPod
はshoes PodへのPOSTのみ可能
(要mTLS)
§ usersへは無条件でアクセス可能(初期値)
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
...
spec:
selector:
matchLabels:
app: shoes
rules:
- from:
- source:
principals: ["cluster.local/ns/\
default/sa/inventory-sa"]
to:
- operation:
methods: ["POST"]
28
https://istiobyexample.dev/authorization/

View Slide

Observability
§ 可視化ツールと連携可能
◇ Prometheus，Grafana，Jaeger，Kiali
§ Proxyコンテナの標準出⼒としてアクセスログを取得可能
29
画像引⽤元
Grafana: https://istio.io/docs/tasks/observability/metrics/using-istio-dashboard/
Jaeger: https://istio.io/docs/tasks/observability/distributed-tracing/jaeger/
kiali: https://github.com/kiali/kiali
Grafana Kiali
Jaeger

View Slide

ユースケース: Bring Your Own Prometheus
Istio付属のPrometheusではなく
⾃前のPrometheusを使う
① PrometheusのPull対象にistioを追加
② PrometheusにIstioの証明書を追加
③ Istioのインストール設定でGrafanaや
Kialiが参照するPrometheusを変更
30
volumes:
- name: config-volume
configMap:
name: prometheus
- name: istio-certs
secret:
defaultMode: 420
optional: true
secretName: istio.default
https://istiobyexample.dev/prometheus/
istioctl manifest generate \
--set values.prometheus.enabled=false \
--set values.kiali.enabled=true \
--set values.kiali.prometheusAddr="http://promethe
--set values.grafana.enabled=true \
--set values.grafana.datasources.datasources.datas
- job_name: 'pilot'
kubernetes_sd_configs:
- role: endpoints
namespaces:
names:
- istio-system
relabel_configs:
- source_labels:
- __meta_kubernetes_service_name
- __meta_kubernetes_endpoint_port_name
action: keep
regex: istio-pilot;http-monitoring
①
②
③

View Slide

Cluster Expansion
§ クラスタを超えてIstioのMesh(ネットワーク)を構築できる
◇ 複数Kubernetesクラスタ延伸
◇ VM延伸
§ ハイブリッドクラウドやシステムの地理分散，VM連携が可能
§ 複数Kubernetesクラスタの構成は複数パターン存在
◇ Control Planeを共有 ↔ クラスタごとにControl Plane作成
◇ ネットワークを共有 ↔ 個別ネットワーク
31

View Slide

ユースケース: Virtual Machine
PostgreSQL VMをMeshに追加
§ VM側にProxyをインストール
§ ServiceEntryリソースにてPodから
VMへの通信を許可
§ istioctl registerでVMのIPアドレスに
対するServiceとEndpointを作成
32
https://istiobyexample.dev/virtual-machines/
https://istio.io/docs/examples/virtual-machines/single-network/
kind: ServiceEntry
...
spec:
hosts:
- ${VM_NAME}.default.svc.cluster.local
ports:
- number: ${PORT}
name: tcp
protocol: TCP
resolution: STATIC
endpoints:
- address: ${VM_IP}
ports:
tcp: ${PORT}
labels:
app: ${VM_NAME}
istioctl register -n default ${VM_NAME}
${VM_IP} tpc:${PORT}
istioctl experimental
add-to-meshコマンドにて
ServiceEntryとregisterを
⼀度に作成できるが, まだ実験
段階につき本番利⽤は⾮推奨

View Slide

Istio活⽤に向けた⽇⽴での取り組み
33

View Slide

⽇⽴でのIstio活⽤
§ ⽇⽴では2018年から社内向けサービスにIstioを導⼊し，
システムの運⽤性向上およびIstioノウハウの蓄積を実施
(詳細は下記スライド参照)
§ 運⽤中に得た気付きや，それを基にIstioコミュニティに
提案中の機能を紹介します
34
SpeakersDeck, 1年間のシステム運⽤を通して分
かったIstioの嬉しさと活⽤における注意点

View Slide

Pod間通信可否の静的チェック機能
気付き
§ サービス間での通信可否には物理, K8s,
Istio, Appと様々な要素が絡む
§ サービス間での通信失敗時，Istioの設
定上の問題なのかそれ以外かの切り分
けに時間を要する
提案機能
§ istioctl analyze connect機能
§ Istioの設定情報を静的解析し，
通信可否を判定
§ Istio GitHubのIssueにて議論中
35

View Slide

性能評価⾃動化ツール「istio-bench」 1/2
気付き
§ IstioはPod数に⽐例してProxyや
ControlPlaneのリソース消費量が増⼤
§ ⼤規模クラスタではリソース設計要
§ しかし, リソース消費傾向は設定や
バージョンで変化し, 評価が⼤変
提案機能 istio-bench
§ Pod数に応じた計算リソース消費量を
計算するベンチマーカー
§ GitHubで公開。コミュニティに提案したい
https://github.com/Hitachi/istio-bench/
36

View Slide

性能評価⾃動化ツール「istio-bench」 2/2
Istio-benchの動作
§ ダミーPodを50個デプロイし，Istio関連の計算リソース消費量を測定
§ ダミーPodが500個になるまで1を繰り返し, 近似式を算出
§ グラフおよびcsvデータを出⼒
37

View Slide

(参考)プロキシメモリ消費量の変遷
38
§ 1000Podのときの各Envoyの消費メモリ
§ v1.0のときに急激に削減。それ以降も緩やかに削減中
771MB
268MB
163MB
145MB 127MB
76MB 72MB
0
200
400
600
800
1000
1.0.2 1.0.7 1.1.7 1.2.9 1.3.2 1.4.5 1.5.0
メモリ消費量[MB]
Istioのバージョン

View Slide

(参考)コントロールプレーンのリソース消費量変遷
§ 1000Podのときのpilotとistiodのリソース消費量
§ 精度はあまり⾼くないが，以前より急激に増加したようには⾒えない
39
261 249
0
50
100
150
200
250
300
1.4.5
(istio-pilot)
1.5.0
(istiod)
CPU使⽤率[%]
816
439
0
200
400
600
800
1000
1.4.5
(istio-pilot)
1.5.0
(istiod)
メモリ消費量[MB]
27
32
0
5
10
15
20
25
30
35
1.4.5
(istio-pilot)
1.5.0
(istiod)
通信量(tx)[Mbps]
3
10
0
2
4
6
8
10
12
1.4.5
(istio-pilot)
1.5.0
(istiod)
通信量(rx)[Mbps]

View Slide

(参考)pilotとistiodでメモリ消費量の増加傾向が違う
§ pilotはPod数に関わらず⼀定(左オレンジ線)
§ istiodはPod数に⽐例(右オレンジ線)
§ Podが1650個を超えるとistiodの⽅がリソースを消費
§ 精度が低いため, あくまで参考値。理由含めて今後深堀り予定
40

View Slide

まとめ
Service Meshはマイクロサービスの運⽤を助けるもの
§ 各サービスから透過的に，システム全体に
渡って⼀貫性のある通信制御を⾏う
IstioもService Meshの⼀実装
§ 機能: 通信管理, セキュリティ管理, 可観測性, クラスタ延伸
§ 導⼊時はユースケースの有無と運⽤可否を検討する
⽇⽴も社内サービスにてIstioを活⽤中
§ 運⽤の経験を基に機能を提案中
§ istio-benchをリリースしました
41

View Slide

View Slide

Trademarks
§ Istioは、Google LLCの⽶国における登録商
標または商標です
§ Envoyは、The Linux Foundationの⽶国ま
たはその他の国における登録商標または商
標です
§ Kubernetesは、The Linux Foundationの
⽶国またはその他の国における登録商標また
は商標です
§ Prometheusは、The Linux Foundationの
⽶国またはその他の国における登録商標また
は商標です
§ Grafanaは、Grafana Labsの⽶国またはそ
の他の国における登録商標または商標です
§ Jaegerは、 The Linux Foundationの⽶国
またはその他の国における登録商標または商
標です
§ Kialiは、 Red Hat, Inc.の⽶国またはその他
の国における登録商標または商標です
§ Istio by ExampleはGoogle LLC所属の
Megan O‘Keefe⽒の著作物です
§ その他記載の会社名、製品名、サービス名、
その他固有名詞は、それぞれの会社の商標
または登録商標です
§ 本発表中の⽂章、図では、TM、マークは
表記しておりません
43

View Slide

Istio Overview

Istio Overview

id

More Decks by id

Other Decks in Technology

Featured

Transcript