Istio, Kubernetes and Cloud Foundry
•
7 j'aime•2,224 vues
※補足文が小さくて読みづらい方は修正版をご覧ください https://www.slideshare.net/jacopen/istio-kubernetes-and-cloud-foundry-99649855 Container SIGで発表した資料です。Istioはk8sのみでなくCloud Foundryにも、Microservicesで嬉しい機能をもたらします。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Istio, Kubernetes and Cloud Foundry
Similaire à Istio, Kubernetes and Cloud Foundry (20)
Plus de Kazuto Kusama
Plus de Kazuto Kusama (20)
Dernier
Dernier (9)
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 Breakerなどの仕組みを備える必要があります
- 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. と、Istioがどう関係するのか
- 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.