Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Istio, Kubernetes and Cloud Foundry (修正版)

1,309 views

Published on

Container SIGで発表した資料です。
文字サイズを変えた修正版です

Published in: Technology
  • Be the first to comment

Istio, Kubernetes and Cloud Foundry (修正版)

  1. 1. Pivotal Japan - Solutions Architect Kazuto Kusama @jacopen
  2. 2. そんなわけで今日はIstioの話をしよ うと思うんですが、その前に
  3. 3. で アプリを開発 運用している人? 今回参加されている方々は開発者や、インフラ運 用者だと思うのですが、Microservices Architectureなアプリを開発/運用している方って どのくらい居ますか? (会場の1割くらい手が上がる)
  4. 4. 考えることが いっぱい Microservicesな開発しよう と思うと、結構考えなきゃい けないポイント多いんですよ ね
  5. 5. たとえば app A app B app CMicroservicesでは複数のアプリが上がって通信し合うワ ケですが、セキュリティは担保したいですよね。信頼できる アプリからのみ受け付けるようにしたい。 となると、相互TLSなどの仕組みが必要になってくる。
  6. 6. たとえば app app app app app Observabilityっていう単語もありますが、どこでどういった通信 が行われているか、問題なく動いているか、全ての箇所でログ やメトリクスを収集する必要がありますよね。
  7. 7. たとえば app app app C app app 呼び出し先がスローダウンした場合、呼び出し元のアプリもレスポンス待 ちになる可能性があるわけです。すると、そのアプリを呼び出す他のアプ リが・・・と。これを防ぐには、Circuit Breakerなどの仕組みを備える必要が あります
  8. 8. 現状 app app app app app 様々なツールやライブラリを使って実現。 サービスメッシュが複雑になるにつれ、より管理が 難しくなるのが現状 ライブラリ依存により の実現が困難に 今まではツールやライブラリを組み合 わせて解決を図っていました。 これでもMicroservicesは組めるわけで すが、サービスメッシュが複雑になるに つれ開発や運用の負担は増していきま す。 また、ライブラリ依存により、 Microservicesのメリットの一つである Polyglotが損なわれてしまう可能性もあ ります。
  9. 9. そこで登場するのが、Istio です
  10. 10. app app app L7/L4 ProxyであるEnvoyを各アプリとセッ トで立ち上げ、各サービスはアプリ直では なくEnvoyに対して通信を行います
  11. 11. app app app Pilot Mixier Istio Auth さらにこれらをコントロールするControl Planeが組み合わさったのが、Istioです。
  12. 12. その他詳しい情報 と共にマイクロサービスに立ち向かえ まずは試そう Istioについて まとまった知識が欲しいなら そもそもService Meshとは 日本語で概要を把握 したいときにおすすめ 世の中には優れた情報がたくさ んありますので、今回はIstioの 詳細までは踏み込みません。 興味のある方は、これらリンク を参考にしてください。
  13. 13. ところで を必要とするのはどういう人なの? やっていないと は必要ないの? ⇒ 基本的には など、 だからこそ欲しくなる機能が にはたくさん
  14. 14. これはどうかな? App v1 App v1 App v1 App v2 90% 10% Canary release App v1 App v1 App v1 App v2 ^(.*?;)?(user=jacopen)(;.*)?$ Feature Flag Canary release: (例) 重み付けをすることでトラフィックの10% を新アプリにFeature Flag: (例) 特定のcookieやヘッダを持つ 相手に対してのみ新アプリに これは、Microservicesに関わらず欲しい機能じゃないでしょう か
  15. 15. で、 地獄が加速 apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: details-default namespace: default ... spec: destination: name: details precedence: 1 route: - labels: version: v1 --- apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: productpage-default namespace: default ... spec: destination: name: productpage precedence: 1 route: - labels: version: v1 apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: ratings-default namespace: default ... spec: destination: name: ratings precedence: 1 route: - labels: version: v1 --- apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: reviews-default namespace: default ... spec: destination: name: reviews precedence: 1 route: - labels: version: v1 apiVersion: v1 kind: Service metadata: name: details labels: app: details spec: ports: - port: 9080 name: http selector: app: details --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: details-v1 spec: replicas: 1 template: metadata: labels: app: details version: v1 spec: containers: - name: details apiVersion: v1 kind: Service metadata: name: ratings labels: app: ratings spec: ports: - port: 9080 name: http selector: app: ratings --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: ratings-v1 spec: replicas: 1 template: metadata: labels: app: ratings version: v1 spec: containers: - name: ratings image: istio/examples-bookinfo-ratings-v1 :1.5.0 k8sのメリットでありデメリットでもあるのですが、大量の YAMLと付き合わなければいけません。 Istioを導入すると、さらにYAMLが増えます。
  16. 16. もっと簡単な方法で アプリのデプロイ の恩恵にあずかれないか?
  17. 17. これまでの CFというとPaaSというイメージを持つ方も多いと思います が、現在はCFAR(PaaS)とCFCR(Kubernetes)の2つを指 すブランドになっています。 今回は、CFAR(PaaS)についての話をします
  18. 18. を含めた のいいところ $ cf push app-v1 コンテナを意識せずとも ソースコードを するだけでアプリが動く アプリの運用に必要な機能 監視 ロギング メトリクス が最初から揃っている CFAR(PaaS)とk8s(CaaS)の大きな違いとして、PaaSは開発者のエクスペリエン スに特化しており、コンテナの存在を意識せずともアプリのデプロイができる点に あります。運用も色々揃ってます。 ※詳しくは私のスライドも参考にしてください
  19. 19. と、 がどう関係するのか
  20. 20. 先に結論 近い将来、 の 部分は に置き換えられ ・既にある の機能 ・ によって実現される新機能 が、 の使い勝手を損なうこと無く利用できるようになります
  21. 21. 現在の の仕組み 今のCFの仕組み: 全てのトラフィッ クをRouterというコンポーネントが 受け取り、リクエストヘッダに応じ て適切にルーティング。
  22. 22. 現在の の仕組み メッセージングバス から情報受け取り アプリを立ち上げると メッセージングバスに 通知 Diego Cellというコンポーネントが、自身 のもつコンテナの情報をMessaging Bus にPublishします。 Routerはその情報をSubscribeしている ので、どこに何のアプリが上がっているか 把握できるわけです
  23. 23. これまでの などバックエンドサービスへ の トラフィックが 中心 これまでは、インターネットから来るリクエ ストをアプリにルーティングする、 North-Southのトラフィックが中心でした。 なので、Messaging Busを使う仕組みは 上手く機能していました
  24. 24. これからの のトラフィックが 多く発生 しかしMicroservices時代になり、コンテナ 同士の通信(East-West)のトラフィックが 多く発生するようになりました。
  25. 25. いろいろ欲しくなる 結果として、相互TLSやサーキットブレー カー、サービスディスカバリ、トラフィックコ ントロールなどの仕組みが欲しくなってき ました。 既存の仕組みだけでは、徐々に実現が難 しくなったわけです。
  26. 26. なんとかしたい
  27. 27. 選択肢 既存のサービスメッシュ • 重い • オーケストレーターに依存しない • に特化 自前 • ちゃんとメンテ出来る? • 独自性出せる? • 労力に見合った価値出せる? CFの開発チームは色々検討しました。 他の仕組みの導入だけでなく、自前で開 発も視野にいれてPros/Consを検討した 結果、Istioの選択がベストという結論に 至ったようです。
  28. 28. の大変革 • と を取り入れた 新しい に ということで、既存のRouting Tierを置き換 える大胆なProposalが出ています。
  29. 29. 利用例 $ cf push app-v1 コンテナを意識せずとも ソースコードを するだけでアプリが動く $ cf push app-v2 新バージョンを 既存のCFのワークフロー 既存のフローで、古いバージョンと新し いバージョンのアプリをデプロイしてお きます。 コマンド2つだけ。楽ちんですね
  30. 30. 利用例 $ cf map-route app-v1 example.com -n foo --weight 90 $ cf map-route app-v2 example.com -n foo --weight 10 の を に割り当て の を に割り当て cfコマンドで重み付けを簡単設定 それぞれのアプリに対しての重み付けを行います。 --weightというパラメータを付け加えるだけです。YAML 不要でかなりシンプルですよね。 開発者が欲しいのはYAML地獄ではなく、このシンプル さなんじゃないでしょうか
  31. 31. 利用例 $ cf istio-create -f ingress-rule.yml Istio-nativeなやり方もとれる metadata: name: my-rule namespace: default spec: route: - labels: name: app-v1 weight: 90 - labels: name: app-v2 weight: 10 とはいえYAMLには柔軟な設定が可能 というメリットもあるため、Istio-nativeな 方法もとれるよう考えられているようで す。
  32. 32. 進め方 • いきなり に置き換えることはしない • 徐々に実装
  33. 33. の実装 済 Envoyのsidecarはもう実装されてお り、最新のCFで利用されています。
  34. 34. 間の 化 済 RouterとApp間を相互TLSで通信する 仕組みも、既に実装されています。
  35. 35. 用の 実装 済 Service Discoveryの機能もすでに実 装済みです
  36. 36. の実装
  37. 37. を に
  38. 38. の実装
  39. 39. ゴール - デモが で動くこと 外部からのリクエストを受け付けられる 内のアプリ間でルーティングできる アプリ間で透過的な相互認証ができる アプリ開発者がルーティングのルールを設定できる 重み付けルーティングができる - のサポート - 既存の と同等機能のサポート - サポート - のサポート -
  40. 40. まとめ • は を実現するにあたって必要な ピースを提供してくれる • に限らず、 にもガッツリと 実装されていく • やることが必須ではないが、プラットフォームはどんど ん 向けの機能が追加されていく。 ○ これまで足かせになっていたポイントがプラットフォーム側で担保されるようになるので、 改めてスケールするアーキテクチャ・組織を考え始めてもいいかも

×