© Hitachi, Ltd. 2019. All rights reserved. 1年間のシステム運⽤を通して分かった Istioの嬉しさと活⽤における注意点 #cndk2019 #roomB 株式会社 ⽇⽴製作所 研究開発グループ 井出 貴也 CloudNative Days Kansai 2019

© Hitachi, Ltd. 2019. All rights reserved. § ServiceMeshやIstioが注⽬を集めている ü IstioはGitHubのFastest Growing Projectの第4位 § ⼀⽅で，国内でのIstio活⽤事例はまだ少数 Q. 実サービスに導⼊済の⼈ Q. 検証中の⼈ Q. 使ったことがある⼈ Q. 概要を知っている⼈ § ⽇⽴では社内向けシステムにIstioを導⼊し，1年に渡って運⽤ § そこで得たIstioの嬉しさや問題点， 問題への対策といったプラクティスを共有します 本セッションの趣旨 1

© Hitachi, Ltd. 2019. All rights reserved. 内容 1. なぜServiceMeshが求められるのか 2. Istioとは? 3. 社内でのIstio活⽤ユースケース 4. 運⽤を通して分かったこと 2

© Hitachi, Ltd. 2019. All rights reserved. なぜServiceMeshが求められるのか 3

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

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

© Hitachi, Ltd. 2019. All rights reserved. Microserviceの運⽤ § ⼤きなMicroserviceをどう運⽤するか ü サービス間のルーティングは？ ü 通信先のサービスが落ちていた場合の対応は？ ü 通信のアクセス制御は？ ü システム全体の可視化は？ § 各サービスチームが上記課題を個別解決 → ✕ ü 開発・運⽤の⼯数が⼤きい ü 仕様や品質がバラバラになる § 個々のサービスに影響を与えず， システム全体に渡って⼀貫性のある解決⼿段が求められる → ServiceMeshというアイデア 6

© Hitachi, Ltd. 2019. All rights reserved. 7 Istio

© Hitachi, Ltd. 2019. All rights reserved. Istioとは？ 8

© Hitachi, Ltd. 2019. All rights reserved. Istio Overview § GoogleとIBMが開発するOSSのServiceMesh実装 ü ⾼機能，⾼い知名度 ü 機能⽐較：INNOQ Service Mesh Comparison https://servicemesh.es/ ü 「servicemesh es」で検索 § 価値： 個々のサービスから透過的に システム全体に渡って⼀貫性のある⽅法で サービス間通信を管理 9

© Hitachi, Ltd. 2019. All rights reserved. Istioの挙動 10 Pod Pod Service Container Container Service Kuberntes内の通信はServiceを 介してPod内のコンテナに届く Ingress

© Hitachi, Ltd. 2019. All rights reserved. Pod Pod Container Container Istioの挙動 Service Kuberntes内の通信はServiceを 介してPod内のコンテナに届く Istioは各Podに透過プロキシサーバ を挿⼊。プロキシ経由でコンテナ に通信が届く Service Proxy 11 Proxy Proxy

© Hitachi, Ltd. 2019. All rights reserved. Istioの挙動 Pod Pod Proxy Proxy Container Container Service Kuberntes内の通信はServiceを 介してPod内のコンテナに届く Proxy Service Control Plane 12 Istio Control Planeが 各プロキシを動的制御 Istioは各Podに透過プロキシサーバ を挿⼊。プロキシ経由でコンテナ に通信が届く

© Hitachi, Ltd. 2019. All rights reserved. Istioの挙動 Pod Pod Proxy Proxy Container Container Service Service Kuberntes内の通信はServiceを 介してPod内のコンテナに届く Proxy Istio Control Planeが 各プロキシを動的制御 端点を抑えているため、コンテナ から透過的にネットワークを制御 できる 13 Control Plane Routing Monitoring Access Ctrl Late Limit etc. Istioは各Podに透過プロキシサーバ を挿⼊。プロキシ経由でコンテナ に通信が届く

© Hitachi, Ltd. 2019. All rights reserved. Istioの挙動 Pod Pod Proxy Proxy Container Container Service Service Kuberntes内の通信はServiceを 介してPod内のコンテナに届く Proxy Istio Control Planeが 各プロキシを動的制御 端点を抑えているため、コンテナ から透過的にネットワークを制御 できる 14 Routing Monitoring Access Ctrl Late Limit etc. Istioは各Podに透過プロキシサーバ を挿⼊。プロキシ経由でコンテナ に通信が届く Control Plane

© Hitachi, Ltd. 2019. All rights reserved. Istio Control Plane § Pilot ü プロキシへの設定デリバリ ü Service Discovery § Mixer ü メトリクス収集 ü Policyチェック § Citadel ü TLSの鍵管理 § Galley ü 基盤システム(k8s)連携 15 https://istio.io/docs/concepts/what-is-istio/

© Hitachi, Ltd. 2019. All rights reserved. Istioの挙動 Pod Pod Proxy Proxy Container Container Service Service Kuberntes内の通信はServiceを 介してPod内のコンテナに届く Proxy Istio Control Planeが 各プロキシを動的制御 端点を抑えているため、コンテナ から透過的にネットワークを制御 できる 16 Istioは各Podに透過プロキシサーバ を挿⼊。プロキシ経由でコンテナ に通信が届く Control Plane Routing Monitoring Access Ctrl Late Limit etc.

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

© Hitachi, Ltd. 2019. All rights reserved. Istio機能 § 通信管理 Traffic Management Service Discovery, Dynamic Request Routing, Load Balancing, Mirroring, Splitting, Shaping, Timeout, Retry, CORS, Circuit Braking, Chaos Engineering § セキュリティ管理 Security Management Authorization, Authentication, Access Control, TLS key management, etc. § 可観測性 Observability Monitoring, Logging, Distributed Tracing 18 → ⾯⽩い機能をいくつか抜粋して紹介

© Hitachi, Ltd. 2019. All rights reserved. Traffic Management § Dynamic Request Routing ü ポリシーに基づく動的な通信制御 ü ルーティングに利⽤可能な値 ü Kubernetes情報：Namespace，Service，Label... ü トラフィック情報：URI，HTTP Method，HTTP Header... ü VirtualServiceリソースとDestinationRuleリソースで制御 ü MirroringやSplittingとも連携でき，とても柔軟な通信制御を実現 19

© Hitachi, Ltd. 2019. All rights reserved. § カナリアリリース § ユーザ通信のうち 90% は v1 の app に, 10% は v2 の app に転送 Proxy Container version: v1 Proxy Container version: v2 90% 10% app 例 | ポリシーに基づく動的な通信制御 20 https://istio.io/blog/2017/0.1-canary/

© Hitachi, Ltd. 2019. All rights reserved. apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: canary spec: hosts: - app http: - route: - destination: host: app subset: v1 weight: 90 - destination: host: app subset: v2 weight: 10 § カナリアリリース § ユーザ通信のうち 90% は v1 の app に, 10% は v2 の app に転送 Proxy Container version: v1 Proxy Container version: v2 90% 10% app 例 | ポリシーに基づく動的な通信制御 21 apiVersion: networking.ist kind: DestinationRule metadata: name: canary spec: host: app subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 https://istio.io/blog/2017/0.1-canary/

© Hitachi, Ltd. 2019. All rights reserved. apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: canary spec: hosts: - app http: - route: - destination: host: app subset: v1 weight: 90 - destination: host: app subset: v2 weight: 10 § カナリアリリース § ユーザ通信のうち 90% は v1 の app に, 10% は v2 の app に転送 Proxy Container version: v1 Proxy Container version: v2 90% 10% app 例 | ポリシーに基づく動的な通信制御 22 apiVersion: networking.ist kind: DestinationRule metadata: name: canary spec: host: app subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 https://istio.io/blog/2017/0.1-canary/ Labelに 紐付け 割合を指定

© Hitachi, Ltd. 2019. All rights reserved. apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: canary spec: hosts: - app http: - match: - headers: cookie: regex: "^(.*?;)?(email=[^;]*@foobar.com)(;.*)?$" route: - destination: host: app subset: v1 weight: 90 - destination: host: app subset: v2 weight: 10 - route: - destination: host: app subset: v1 § カナリアリリース § foobar.comのメールアドレスを 持つユーザ通信のうち, 90% は v1 のアプリに, 10% は v2 のアプリに転送 例2 | ポリシーに基づく動的な通信制御 23 https://istio.io/blog/2017/0.1-canary/ apiVersion: networking.istio.io/v1alph kind: DestinationRule metadata: name: canary spec: host: app subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 Proxy Container version: v1 Proxy Container version: v2 app [email protected] 90% 10% 100%

© Hitachi, Ltd. 2019. All rights reserved. § カナリアリリース § foobar.comのメールアドレスを 持つユーザ通信のうち, 90% は v1 のアプリに, 10% は v2 のアプリに転送 例2 | ポリシーに基づく動的な通信制御 24 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: canary spec: hosts: - app http: - match: - headers: cookie: regex: "^(.*?;)?(email=[^;]*@foobar.com)(;.*)?$" route: - destination: host: app subset: v1 weight: 90 - destination: host: app subset: v2 weight: 10 - route: - destination: host: app subset: v1 https://istio.io/blog/2017/0.1-canary/ apiVersion: networking.istio.io/v1alph kind: DestinationRule metadata: name: canary spec: host: app subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 Proxy Container version: v1 Proxy Container version: v2 app [email protected] cookieにfoobar.comの メールアドレスを含む 含まない ※ cookieにユーザ情報を格納する ことはセキュリティ上の懸念あり 90% 10% 100%

© Hitachi, Ltd. 2019. All rights reserved. Security and Policy § サービス間認証 ü mTLS：サーバとクライアント双⽅が証明書で互いを認証する ü 受信側のmTLSはPolicyリソース，送信側のｍTLSはDestinationRuleで設定 ü 設定が複数リソースにまたがるため混乱しやすい § 認可 ü L7レベルのアクセス制御を⾏う ü 認可の条件にはk8sの情報とトラフィックの情報が利⽤できる ü ただし，k8sの情報は「送信元がプロキシ経由」&&「mTLS」が条件 ü Kubeletからのhealth checkは送信元がプロキシ経由ではないため落とされる → health checkを受け⼊れる設定ができた(rewriteAppHTTPProbers) 25

© Hitachi, Ltd. 2019. All rights reserved. Observability § アドオンとしていくつかの可視化ツールと連携 ü Prometheus，Grafana，Jaeger，Kiali § 相応の計算リソースを消費するため注意 26 画像引⽤元 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. 2019. All rights reserved. 社内でのIstio活⽤ユースケース 27

© Hitachi, Ltd. 2019. All rights reserved. 対象システム § 社内の開発者向けに開発環境を提供するサービス ü Webエディタやバックエンドサービスなどを提供 ü バックエンドサービスは各チームが⾃律的に開発 § Kubernetesベース。100+ Nodes，2000+ Pods 28 Kubernetes Web Editor Backend Service 1 Backend Service 2 App App開発, 実⾏ 社内開発者 (ユーザ) Backend Service1 開発チーム Backend Service2 開発チーム 呼び出し プラットフォーム チーム Backend Service1開発 Backend Service2開発 環境構築,運⽤ 稼働

© Hitachi, Ltd. 2019. All rights reserved. Istio導⼊のモチベーション 1. サービス間通信を管理したい ü 柔軟なルーティング ü サービス間アクセス制御 ü 通信メトリクスの収集 2. しかし，バックエンドサービス の内部には⼲渉したくない 3. Istioのトレンドが急浮上 29 検証も兼ねてIstioを導⼊ 本番環境で1年ほど運⽤ Kubernetes Web Editor Backend Service 1 Backend Service 2 App App開発, 実⾏ 社内開発者 (ユーザ) Backend Service1 開発チーム Backend Service2 開発チーム 呼び出し プラットフォーム チーム Backend Service1開発 Backend Service2開発 環境構築,運⽤ 稼働

© Hitachi, Ltd. 2019. All rights reserved. 運⽤を通して分かったこと 30

© Hitachi, Ltd. 2019. All rights reserved. 総評 便利だが 運⽤負荷は重い § 運⽤負荷をペイできるユースケースがあるか § 運⽤体制は整っているか 31 運⽤負荷以外にも観点はある • システムの複雑化を許容できるか? • リソースの消費は? • レイテンシの追加は?

© Hitachi, Ltd. 2019. All rights reserved. 総評 便利だが 運⽤負荷は重い § 運⽤負荷をペイできるユースケースがあるか § 運⽤体制は整っているか 32 運⽤負荷以外にも観点はある • システムの複雑化を許容できるか? • リソースの消費は? • レイテンシの追加は?

© Hitachi, Ltd. 2019. All rights reserved. Istioを利⽤して良かった点 1. サービスから透過的な通信管理 2. Kubernetesネイティブ 3. コミュニティの活発さ 33

© Hitachi, Ltd. 2019. All rights reserved. 良かった点1｜サービスから透過的な通信管理 § 個々のサービスを改修しなくて良い ü OSSや既存プロダクトなど，改修が⼤変なアプリを使う際に便利 ü Auto-Injection機能によりプロキシの⾃動挿⼊もできる ü サービスチームとのコミュニケーションコストも少ない（はず） § 柔軟・⾼機能な通信管理 ü NamespaceやLabelによるルーティング・アクセス制御 ü 今までサービス内で設定していたリトライ数やタイムアウト， サーキットブレイクなどの設定もできる 34

© Hitachi, Ltd. 2019. All rights reserved. 良かった点2｜Kubernetesネイティブ § Istioの全制御がカスタムリソースで完結 ü HelmなどのKubernetesエコシステムを活⽤できる § Istio本体もKubernetesで動作 ü Replicaによる可⽤性 ü Horizontal Pod Autoscalingによるスケーラビリティ ü ControlPlaneの処理負荷には注意 § 宣⾔的ネットワーク管理 ü 設定ファイルがそのままネットワーク構成の定義になる ü CI/CDやGitOpsの世界観でネットワークを管理 35

© Hitachi, Ltd. 2019. All rights reserved. 良かった点3｜コミュニティの活発さ § コミュニティが⼤きく，活発 ü Issueの平均対応時間：5⽇※1 ü 隔週レベルでのパッチアップデート ü v1.1以降品質も安定 § 情報も多い ü 公式ドキュメント，Issue，書籍，ブログ ü ただし，陳腐化も早い 36 ※1 Istio Project Dashboards https://istio.teststats.cncf.io/d/11/issues-age-by-repository-group?orgId=1

© Hitachi, Ltd. 2019. All rights reserved. 総評 便利だが 運⽤負荷は重い § 運⽤負荷をペイできるユースケースがあるか § 運⽤体制は整っているか 37 運⽤負荷以外にも観点はある • システムの複雑化を許容できるか? • リソースの消費は? • レイテンシの追加は?

© Hitachi, Ltd. 2019. All rights reserved. Istio活⽤における注意点 1. 運⽤難度が⾼い 2. 3ヶ⽉ごとのアップデート 3. サービスとプラットフォームの境界 4. Proxyのメモリ消費 5. 認証・認可のマイグレーション 38

© Hitachi, Ltd. 2019. All rights reserved. 注意点1｜運⽤難度が⾼い § Istioは通信制御, 認証認可, 監視の機能を集約している ü 様々な機能，⾼い⾃由度，無数の設定ファイル ü サービス間の整合担保が⼤変 ü 運⽤に辺り覚えることが多く，属⼈化しやすい § 障害時の原因切り分けが困難 ü 物理, Kubernetes, App,…様々な要素が絡む ü プロキシのタイムアウトで障害が顕在化 → Istioが疑われやすい ü 例: 通信先のアプリが落ちた → Envoy「504 gateway timeouts」 ü 障害時，Istioの名前が上がるため悪いイメージが付きやすい ü デバッグの最終⼿段：Envoyコンテナにnetcatとtcpdumpが⼊っている 39

© Hitachi, Ltd. 2019. All rights reserved. 対策1｜ 社内Istio情報共有Wiki § Istioの情報を⼀元管理する Wikiを作成し社内で情報共有 （社外公開の予定なし） § コンテンツ ü Istioの価値，概要 ü Istioの挙動調査結果 ü 過去の障害情報 ü デバッグ⽅法 ü etc. 40

© Hitachi, Ltd. 2019. All rights reserved. 注意点2｜3ヶ⽉ごとのアップデート § Istioは3ヶ⽉ごとにリリース + 過去1バージョンのみサポート※1 ü バージョンアップへの追従が必要 ü 検証や移⾏の⼯数は⼤きい。⼀⼈は専任した⽅が良い § アップデートに伴う構成の再検討が必要な場合も ü PatchアップデートでServiceEntryの宛先をanyにする設定が禁⽌に § リソース消費量も変化する ○ v1.1からv1.3までの間にPilotの消費メモリは1/5に減少 ✕ envoy_statsdログの出⼒がデフォルトで有効化（1.0.3以降無効化） → Pod数の2乗に⽐例する量のメトリクスを出⼒。輻輳発⽣ 41 ※1 Istio Build & Release Cadence https://istio.io/about/release-cadence/

© Hitachi, Ltd. 2019. All rights reserved. 対策2｜Istio-Operator § Istioの運⽤操作を⾃動化するOperator ü 現在はインストールやアップデートがメイン ü インストールの複雑さを隠す⾼レベルなAPIを提供 ü ValidationやDeprecatedポリシーの適⽤による堅牢性向上 ü Helmによるインストールは今後廃⽌予定 ü マルチクラスタ連携の議論が進んでいる § Istioプロジェクト以外にも2種のIstio-Operatorが存在 ü Banzai Cloud版：OperatorHub.io掲載。マルチクラスタ連携の機能あり ü Maistra版： OpenShiftが採⽤。Kiali，Jaeger，Elasticsearchと連携 42 Introducing the Istio Operator https://istio.io/blog/2019/introducing-istio-operator/

© Hitachi, Ltd. 2019. All rights reserved. 注意点3｜サービスとプラットフォームの境界 § サービスとIstioで機能が重複 ü Timeout，Retry，CORSなどの機能はサービス側にもIstio側にも存在 ü 無理なIstio押し付けはサービスチームの反発をまねく ü 「サービス側でRetryを実装済みだからIstioの機能は使わないよ？」 ü 「HTTPSが前提のOSSを使っているから、 プロキシでHTTPS終端しないで」 § Istioリソースの操作権限問題 ü Istioはクラスタ全体に適⽤される機能がある（例 DestinationRule） ü サービスチームがこれらリソースを⾃由にデプロイ → クラスタ障害 ü ⼀⽅でルーティングやTimeout等の設定はサービスチームに任せたい 43

© Hitachi, Ltd. 2019. All rights reserved. 対策3｜Helm chart化 § Istioの設定をHelm Chartとしてパッケージングし， サービスチームに提供 ü サービスチームに操作してほしい機能のみを 設定項⽬(values)として切り出す ü 公開するポート番号，プロトコル ü Timeout，Retry，etc. § サービスチームは⾃分の使いたい機能をHelmを介して設定 44

© Hitachi, Ltd. 2019. All rights reserved. 注意点4｜プロキシのメモリ消費 § 各プロキシはどうやって他プロキシの宛先を把握しているのか？ → ControlPlaneで宛先リスト(Clusters情報)を作成し，各プロキシに配布 § 弊環境だとPod数に⽐例して宛先リストが増加 ü 宛先リストは各プロキシのメモリに格納 ü Pod数が多くなると，このメモリ消費量が無視できない値に ü 最初期はPod数が1000になると個々のプロキシが750MBのメモリを消費 ü 750MBのメモリを消費するPodが1000個もある!? ü 上⼿くサイジングしないと，OOM KillerでPodやNodeが落ちる ü また，リソース消費傾向はバージョンごとに変化 → リソース管理のためには，Istioアップデートのたびに性能評価要 45

© Hitachi, Ltd. 2019. All rights reserved. 対策4｜性能評価⾃動化ツール「istio-bench」 § Pod数に応じた計算リソース消費量を予測するツール ü ダミーPodを50個デプロイし，Istioコンポーネントの リソース消費量（メモリ・CPU・通信量）をPrometheusから収集 ü ダミーPodが500個になるまで繰り返し, 近似式を算出 § コミュニティに提案したい 46

© Hitachi, Ltd. 2019. All rights reserved. 対策4｜(参考)プロキシのメモリ消費量の変遷 47 § Podが1000個存在するときのプロキシ⼀個あたりの消費メモリを算出 § v1.0の間に急激に減少(嬉しい)。それ以降も緩やかに減少中 771MB 268MB 163MB 145MB 127MB 0 200 400 600 800 1000 1.0.2 1.0.7 1.1.7 1.2.9 1.3.2 メモリ消費量[MB] Istioのバージョン

© Hitachi, Ltd. 2019. All rights reserved. 対策4｜SideCarリソース (alpha) § プロキシを直接制御するリソース § 通信先を限定することで宛先リストのサイズを固定できることを確認 § 設定の抽象度が他と異なる。導⼊するかは未定 48 apiVersion: networking.istio.io/v1alpha3 kind: Sidecar metadata: name: clusters-reducer namespace: default spec: egress: - hosts: - "default/*" - "istio-system/*" Sidecar https://istio.io/docs/reference/config/networking/sidecar/

© Hitachi, Ltd. 2019. All rights reserved. 注意点5｜認証・認可のマイグレーション Istioの機能をいきなりシステム全体に適⽤するとリスク⾼ ⼀⽅で，⼀部のみにIstioを適⽤すると認証・認可が複雑になる § 認証 ü mTLS：クライアントとサーバ双⽅が証明書で互いに認証 ü Istioが適⽤されていないPodはmTLSが使えない ü 送信元はIstio適⽤済みか，宛先は…と適⽤対象を考慮した設定が必要 § 認可 ü 認可条件にKubernetesの情報を使うには， 送信元/宛先双⽅でmTLSの有効化が必須 ü このため，認証と同じ問題があり，Istio配下ではないサービスごとに 認可の⽅法を考える必要あり 49

© Hitachi, Ltd. 2019. All rights reserved. 対策5｜認証のパターン整理 Istio適⽤の有無で通信の条件を整理し，前述のHelm Chartに反映 50 # 送信元 Istio適⽤ 宛先 Istio適⽤ 通信可能な条件 1 済 済 送信側/受信側ともにTLS設定が 有効 or 無効で統⼀されている 2 済 未 送信側でTLS設定が無効化されている 3 未 済 受信側のTLS設定が無効、もしくは mode: PERMISSIVEになっている 4 未 未 無条件で可能。 ただし，⼀切のアクセス制御をかけられない

© Hitachi, Ltd. 2019. All rights reserved. 対策5｜よくあるエラーとその原因の共有 よくあるエラーとその原因をまとめ，プラットフォームチーム内で共有 51 # エラーメッセージ 原因 1 upstream connect error or disconnect/reset before header ü プロキシが落ちている or 調⼦が悪い※1 2 Connection reset by peer ü 認証設定の問題。受信/送信の何れか⼀⽅が mTLSで、もう⽚⽅がPlainTextになっている 3 403 access denied ü 認可設定の不整合，もしくは 送信側がプロキシを経由していない ü 受信側プロキシのログをdebugレベルで⾒て， アクセス情報にNamespace等があればプロキシ経由 ※1 Proxyが落ちるとPodはUnhealthyにはなるが， PID1(pilot-agent)が⽣きているため再起動されない

© Hitachi, Ltd. 2019. All rights reserved. 対策5｜Automatic mutual TLS (Alpha) § Istio 1.4で導⼊された機能 § 送信側mTLS設定（DestinationRule相当）を⾃動で⾏う ü 両⽅ともプロキシが挿⼊されたPod間の通信 → mTLS ü ⽚⽅でもプロキシが無いPod間の通信 → Plain Text § 受信側mTLS設定（Policy）は⼿動設定 52 Automatic mutual TLS https://istio.io/docs/tasks/security/authentication/auto-mtls/ Pod Container Proxy Pod Container Proxy mTLS Pod Container Proxy Pod Container Plain Text

© Hitachi, Ltd. 2019. All rights reserved. [再掲] 総評 便利だが 運⽤負荷は重い § 運⽤負荷をペイできるユースケースがあるか § 運⽤体制は整っているか 53 運⽤負荷以外にも観点はある • システムの複雑化を許容できるか? • リソースの消費は? • レイテンシの追加は?

© Hitachi, Ltd. 2019. All rights reserved. まとめ IstioはMicroserviceの運⽤を⾏うためのもの § サービスから透過的で⼀貫性のある通信管理を実現 § 通信管理，セキュリティ管理，可観測性の機能を持つ 便利だが運⽤負荷は重い § ⾼機能・柔軟な通信制御，Kubernetesネイティブ などの利点あり § しかし，運⽤負荷は重く，プラクティスも発展途上 § コストをペイできるユースケースがあるか 55

© Hitachi, Ltd. 2019. 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.の⽶国またはその 他の国における登録商標または商標で す § その他記載の会社名、製品名、サービ ス名、その他固有名詞は、それぞれの 会社の商標または登録商標です § 本発表中の⽂章、図では、TM、マー クは表記しておりません。 56

No content