Istio, Kubernetes and Cloud Foundry
7 likes2,224 views
※補足文が小さくて読みづらい方は修正版をご覧ください /jacopen/istio-kubernetes-and-cloud-foundry-99649855 Container SIGで発表した資料です。Istioはk8sのみでなくCloud Foundryにも、Microservicesで嬉しい機能をもたらします。
More Related Content
What's hot (20)
Similar to Istio, Kubernetes and Cloud Foundry (20)
More from Kazuto Kusama (20)
Recently uploaded (11)
Istio, Kubernetes and Cloud Foundry
- 1. ? Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0 Istio, Kubernetes and Cloud Foundry
- 2. Pivotal Japan - Solutions Architect Kazuto Kusama @jacopen
- 5. 考えることが いっぱい Microservice Service Discovery Circuit breaker Load barancing Monitoring Logging Traffic control Canary release Blue-green deployment Microservicesな開発しようと思うと、結構考えな きゃいけないポイント多いんですよね
- 6. たとえば AuthN/AuthZ app A app B app CMicroservicesでは複数のアプリが上がって通信 し合うワケですが、どんな通信でも受け付けるっ てのはまずいですよね。信頼できるアプリからの み受け付けるようにしたい。 となると、相互TLSなどの仕組みが必要になって くる。
- 8. たとえば Circuit Breaker app app app C app app 例えば呼び出し先がスローダウンした場合、呼び出し元のアプリもレスポンス待 ちでスローダウンしてしまう可能性があるわけです。すると、そのアプリを呼び出 す他のアプリがスローダウンし???と。 これを防ぐには、Circuit 叠谤别补办别谤などの仕组みを备える必要があります
- 12. Sidecar pattern app app app L7/L4 ProxyであるEnvoyを各アプリとセットで立 ち上げ、各サービスはアプリ直ではなく Envoyに 対して通信を行います
- 13. Istio control plane app app app Pilot Mixier Istio Auth さらにこれらをコントロールする Control Planeが 組み合わさったのが、 Istioです。
- 14. その他詳しい情報 Istio https://istio.io/ Introducing Istio Service Mesh for Microservices https://developers.redhat.com/books/introducing-istio-service-m esh-microservices/ Pattern: Service Mesh http://philcalcado.com/2017/08/03/pattern_service_mesh.html Istioと共にマイクロサービスに立ち向かえ! https://speakerdeck.com/ladicle/istiotogong-nimaikurosabisunili-t ixiang-kae まずは試そう Istioについて まとまった知識が欲しいなら そもそもService Meshとは 日本語で概要を把握 したいときにおすすめ 世の中には優れた情報がたくさんありますので、 今回はIstioの詳細までは踏み込みません。 興味のある方は、是非これらリンクを参考にして ください。
- 15. ところで Istioを必要とするのはどういう人なの？ MicroservicesやっていないとIstioは必要ないの？ ? 基本的にはYes Fault Injection, Service Discovery, Circuit Braker, mTLSなど、 Microservices Architectureだからこそ欲しくなる機能がIstioにはたくさん
- 16. これはどうかな？ App v1 App v1 App v1 App v2 90% 10% Canary release App v1 App v1 App v1 App v2 ^(.*?;)?(user=jacopen)(;.*)?$ Feature Flag とはいえ、例えばこれはどうでしょう。 Istioによって実現ができる Canary releaseですが、重み付 けをすることでトラフィックの 10%を新アプリに、といったリ リースが可能になります。 Feature Flagでは、特定のcookieやヘッダを持つ相手に対 してのみ新アプリに、といったことも実現可能です。 これは、Microservicesに関わらず欲しい機能じゃないで しょうか
- 17. Kubernetes Istio k8s + istioで、YAML地獄が加速 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が増えます。
- 20. これまでの Kubo = Kubernetes BOSH CFというとPaaSというイメージを持つ方も多いと思います が、現在はCFAR(PaaS)とCFCR(Kubernetes)の2つを指 すブランドになっています。 今回は、CFAR(PaaS)についての話をします
- 21. CF(を含めたPaaS)のいいところ $ cf push app-v1 コンテナを意識せずとも ソースコードをpush するだけでアプリが動く app-v1 アプリの運用に必要な機能 (監視,ロギング,メトリクスetc) が最初から揃っている CFAR(PaaS)とk8s(CaaS)の大きな違いとして、 PaaSは開 発者のエクスペリエンスに特化しており、コンテナの存在を 意識せずともアプリのデプロイができる点にあります。運用 も色々揃ってます。 ※詳しくは私のスライドも参考にしてください
- 22. と、滨蝉迟颈辞がどう関係するのか
- 25. Diego cell 現在のRoutingの仕組み Diego cell Diego cell Diego Brain Router Messaging Bus appA.example.com 今のCFの仕組みですが、全てのトラフィックを Routerという コンポーネントが受け取り、リクエストヘッダに応じて適切 にルーティングを行います。 appA.example.comとappB.example.comへのリクエスト は、同じRouterで処理されますがそれぞれ別のアプリに ルーティングできるのです。
- 26. Diego cell Route Emitter 現在のRoutingの仕組み Diego cell Diego cell Diego Brain Router Messaging Bus メッセージングバス から情報受け取り アプリを立ち上げると メッセージングバスに 通知 Route Emitter アプリコンテナを稼働させている Diego Cellというコンポー ネントが、自身のもつコンテナの情報を Messaging Busに Publishします。 Routerはその情報をSubscribeしているので、どこに何の アプリが上がっているか把握できるわけです
- 27. これまでのPaaS Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus RDBなどバックエンドサービスへ North-Southの トラフィックが 中心 これまでのPaaSでは、インターネットから来るリクエストを アプリにルーティングする、北と南 (North-South)のトラ フィックが中心でした。なので、 Messaging Busを使う仕組 みは上手く機能していました
- 28. これからのPaaS Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus East-Westのトラフィックが 多く発生 (Microservices) しかしMicroservices時代になり、コンテナ同士の通信 (East-West)のトラフィックが多く発生するようになりまし た。
- 29. いろいろ欲しくなる Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus mTLS Service Discovery Circuit Braker Traffic Control 結果として、相互TLSやサーキットブレーカー、サービス ディスカバリ、トラフィックコントロールなどの仕組みが欲し くなってきました。 既存の仕組みだけでは、徐々に実現が難しくなったわけで す。
- 30. なんとかしたい
- 31. 選択肢 既存のサービスメッシュ ? Linkerd: 重い ? Istio: オーケストレーターに依存しない ? Conduit: k8sに特化 自前 ? ちゃんとメンテ出来る？ ? 独自性出せる？ ? 労力に見合った価値出せる？ ということで、CFの開発チームは色々検討しました。 他の仕組みの導入だけでなく、自前で開発も視野にいれて Pros/Consを検討した結果、Istioの選択がベストという結論 に至ったようです。
- 32. Routing Tierの大変革 ? Istio PilotとEnvoyを取り入れた 新しいRouing Tierに https://docs.google.com/document/d/1VldkvgWPUh13o5RCNjSvzoPFhbY9BtLqBDdk2k0z9fw/ ということで、既存の Routing Tierを置き換える大胆な Proposalが出ています。
- 33. 利用例 $ cf push app-v1 コンテナを意識せずとも ソースコードをpush するだけでアプリが動く $ cf push app-v2 新バージョンをpush 既存のCFのワークフロー app-v1 app-v1 app-v2 まず既存のCFのフローで、古いバージョンと新しい バージョンのアプリをデプロイしておきます。 コマンド2つだけ。楽ちんですね
- 34. 利用例 $ cf map-route app-v1 example.com -n foo --weight 90 $ cf map-route app-v2 example.com -n foo --weight 10 foo.example.comの90%をapp-v1に割り当て foo.example.comの10%をapp-v2に割り当て cfコマンドで重み付けを簡単設定 app-v1 app-v2 で、それらに対してmap-routeというコマンドで、それぞ れのアプリに対しての重み付けを行います。 --weightというパラメータを付け加えるだけです。 YAML 不要でかなりシンプルですよね。 開発者が欲しいのは YAML地獄ではなく、このシンプル さなんじゃないでしょうか
- 35. 利用例 $ cf istio-create -f ingress-rule.yml Istio-nativeなやり方もとれる app-v1 app-v2 metadata: name: my-rule namespace: default spec: route: - labels: name: app-v1 weight: 90 - labels: name: app-v2 weight: 10 とはいえYAMLにはYAMLで柔軟な設定が可能というメ リットもあるため、Istio-nativeな方法もとれるよう考えら れているようです。
- 37. Envoy sidecarの実装 (済) Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus Envoyのsidecarはもう実装されており、最新の CFで利 用されています。
- 38. Router-App間のmTLS化(済) Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus RouterとApp間を相互TLSで通信する仕組みも、既に 実装されています。
- 39. Container-to-Container用のDNS実装(済) Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus BOSH DNS Service Discoveryの機能もすでに実装済みです
- 40. Client-side load-balancingの実装 Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus
- 41. Edge RouterをEnvoyに Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus
- 42. Istio Pilotの実装 Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus
- 43. ゴール Near-term - BookinfoデモがCFで動くこと - 外部からのリクエストを受け付けられる - CF内のアプリ間でルーティングできる - アプリ間で透過的な相互認証ができる - アプリ開発者がルーティングのルールを設定できる - 重み付けルーティングができる - HTTP/2のサポート Longer-term - 既存のCF Routingと同等機能のサポート - UDPサポート - User-provided TLS keypairのサポート - Mesh Egress
- 44. まとめ ? IstioはMicroservicesを実現するにあたって必要な ピースを提供してくれる ? Kubernetesに限らず、Cloud Foundryにもガッツリと 実装されていく ? Microservicesやることが必須ではないが、プラットフォームはどんど んMicroservices向けの機能が追加されていく。 ○ これまで足かせになっていたポイントがプラットフォーム側で担保されるようになるので、 改めてスケールするアーキテクチャ?組織を考え始めてもいいかも
- 45. Transforming How The World Builds Software ? Copyright 2017 Pivotal Software, Inc. All rights Reserved.