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

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

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

© Hitachi, Ltd. 2020. All rights reserved. なぜService Meshが求められるのか 3

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

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

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

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

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

© Hitachi, Ltd. 2020. All rights reserved. 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

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

© Hitachi, Ltd. 2020. All rights reserved. Istioとは？ 11

© Hitachi, Ltd. 2020. All rights reserved. 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

© Hitachi, Ltd. 2020. All rights reserved. § 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

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

© Hitachi, Ltd. 2020. All rights reserved. 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/

© Hitachi, Ltd. 2020. All rights reserved. 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/

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

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

© Hitachi, Ltd. 2020. All rights reserved. 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

© Hitachi, Ltd. 2020. All rights reserved. Istioのユースケースと機能 20

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

© Hitachi, Ltd. 2020. All rights reserved. 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種 私的にはもう⼀種存在

© Hitachi, Ltd. 2020. All rights reserved. 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

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

© Hitachi, Ltd. 2020. All rights reserved. ユースケース: 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

© Hitachi, Ltd. 2020. All rights reserved. ユースケース: Ingress クラスタ外からの通信を受け付ける § 外部からの通信をGatewayリソースでメッ シュ内に引き⼊れるイメージ https://istiobyexample.dev/ingress/ 26 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: hello-gateway spec: selector: istio: ingressgateway # use default servers: - port: number: 80 name: http protocol: HTTP hosts: - "hello.com" --- apiVersion: networking.istio.io/v1alpha3 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にて 制御

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

© Hitachi, Ltd. 2020. All rights reserved. ユースケース: 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/

© Hitachi, Ltd. 2020. All rights reserved. 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

© Hitachi, Ltd. 2020. All rights reserved. ユースケース: 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 ① ② ③

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

© Hitachi, Ltd. 2020. All rights reserved. ユースケース: 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/ apiVersion: networking.istio.io/v1alpha3 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を ⼀度に作成できるが, まだ実験 段階につき本番利⽤は⾮推奨

© Hitachi, Ltd. 2020. All rights reserved. Istio活⽤に向けた⽇⽴での取り組み 33

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

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

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

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

© Hitachi, Ltd. 2020. All rights reserved. (参考)プロキシメモリ消費量の変遷 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のバージョン

© Hitachi, Ltd. 2020. All rights reserved. (参考)コントロールプレーンのリソース消費量変遷 § 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]

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

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

No content

© Hitachi, Ltd. 2020. All rights reserved. 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