Upgrade to Pro — share decks privately, control downloads, hide ads and more …

1年間のシステム運用を通して分かったIstioの嬉しさと活用における注意点 / Benefits and Usage Notes of Istio

id
November 28, 2019

1年間のシステム運用を通して分かったIstioの嬉しさと活用における注意点 / Benefits and Usage Notes of Istio

English ver

CloudNative Days Kansai 2019 #CNDK2019

日々複雑化するマイクロサービスを運用するにあたり,サービスメッシュ実装のIstioが注目を集めています。しかし,Istioの話題性・機能性とは裏腹に,仕様の複雑さやプラクティスの無さのため,実サービスへのIstio導入は依然として敷居が高いです。日立製作所では社内開発環境の提供のため,2000+PodのKubernetesクラスタにて1年に渡りIstioを使ったマイクロサービスの運用に取り組んできました。本講演ではこの運用を通して得たIstio利用時の問題やその対策といったプラクティスを紹介します。

id

November 28, 2019
Tweet

More Decks by id

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  13. © 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に透過プロキシサーバ
    を挿⼊。プロキシ経由でコンテナ
    に通信が届く

    View Slide

  14. © 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に透過プロキシサーバ
    を挿⼊。プロキシ経由でコンテナ
    に通信が届く

    View Slide

  15. © 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

    View Slide

  16. © 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/

    View Slide

  17. © 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.

    View Slide

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

    View Slide

  19. © 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
    → ⾯⽩い機能をいくつか抜粋して紹介

    View Slide

  20. © 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

    View Slide

  21. © 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/

    View Slide

  22. © 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/

    View Slide

  23. © 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に
    紐付け
    割合を指定

    View Slide

  24. © 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%

    View Slide

  25. © 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%

    View Slide

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

    View Slide

  27. © 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

    View Slide

  28. © Hitachi, Ltd. 2019. All rights reserved.
    社内でのIstio活⽤ユースケース
    27

    View Slide

  29. © 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開発
    環境構築,運⽤
    稼働

    View Slide

  30. © 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開発
    環境構築,運⽤
    稼働

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  37. © 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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  42. © 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/

    View Slide

  43. © 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/

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  48. © 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のバージョン

    View Slide

  49. © 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/

    View Slide

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

    View Slide

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

    View Slide

  52. © 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)が⽣きているため再起動されない

    View Slide

  53. © 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

    View Slide

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

    View Slide

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

    View Slide

  56. © 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

    View Slide

  57. View Slide