Istio, Kubernetes and Cloud Foundry

2. Pivotal Japan - Solutions Architect Kazuto Kusama @jacopen

3. そんなわけで今日は Istioの話をしようと思うんですが、その前に

4. Microservices Architectureでアプリを開発or運用している人？ Quetion 今回参加されている方々は開発者だったり、インフラ運用者だったりすると思うのですがそもそもMicroservices Architectureなアプリを開発/運用している方ってどのくらい居ますか？（会場の1割くらい手が上がる）

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などの仕組みが必要になってくる。

7. たとえば Observability app app app app app 最近Observabilityっていう単語も広まりつつありますが、どこでどういった通信が行われいるか、問題なく動いているか、全ての箇所でログやメトリクスを収集する必要がありますよね。

8. たとえば Circuit Breaker app app app C app app 例えば呼び出し先がスローダウンした場合、呼び出し元のアプリもレスポンス待ちでスローダウンしてしまう可能性があるわけです。すると、そのアプリを呼び出す他のアプリがスローダウンし･･･と。これを防ぐには、Circuit Breakerなどの仕組みを備える必要があります

9. 現状 app app app app app 様々なツールやライブラリを使って実現。サービスメッシュが複雑になるにつれ、より管理が難しくなるのが現状ライブラリ依存によりPolyglotの実現が困難にこういった課題に対して、今まではツールやライブラリを組み合わせて解決を図っていました。もちろんコレでもMicroservicesは組めるわけですが、サービスメッシュが複雑になるにつれ開発や運用の負担は増していきます。また、ライブラリ依存により、 Microservicesのメリットの一つであるPolyglotが損なわれてしまう可能性もあります。

10. そこで登場するのが、 Istioです

11. Sidecar pattern Istioの特徴は、Sidecar patternを採用している点にあります

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が増えます。

18. もっと簡単な方法でアプリのデプロイ & Istioの恩恵にあずかれないか？

19. これまでの Kubo = Kubernetes BOSH CFというとPaaSというイメージを持つ方も多いと思いますが、現在はCFAR(PaaS)とCFCR(Kubernetes)の2つを指すブランドになっています。今回は、CFAR(PaaS)についての話をします

20. CF(を含めたPaaS)のいいところ $ cf push app-v1 コンテナを意識せずともソースコードをpush するだけでアプリが動く app-v1 アプリの運用に必要な機能 (監視,ロギング,メトリクスetc) が最初から揃っている CFAR(PaaS)とk8s(CaaS)の大きな違いとして、 PaaSは開発者のエクスペリエンスに特化しており、コンテナの存在を意識せずともアプリのデプロイができる点にあります。運用も色々揃ってます。 ※詳しくは私のスライドも参考にしてください

21. と、Istioがどう関係するのか

22. https://istio.io/docs/

23. 先に結論近い将来、Cloud FoundryのRouting部分はIstioに置き換えられ・既にあるCloud Foundryの機能・Istioによって実現される新機能が、PaaSの使い勝手を損なうこと無く利用できるようになります

24. Diego cell 現在のRoutingの仕組み Diego cell Diego cell Diego Brain Router Messaging Bus appA.example.com 今のCFの仕組みですが、全てのトラフィックを Routerというコンポーネントが受け取り、リクエストヘッダに応じて適切にルーティングを行います。 appA.example.comとappB.example.comへのリクエストは、同じRouterで処理されますがそれぞれ別のアプリにルーティングできるのです。

25. Diego cell Route Emitter 現在のRoutingの仕組み Diego cell Diego cell Diego Brain Router Messaging Bus メッセージングバスから情報受け取りアプリを立ち上げるとメッセージングバスに通知 Route Emitter アプリコンテナを稼働させている Diego Cellというコンポーネントが、自身のもつコンテナの情報を Messaging Busに Publishします。 Routerはその情報をSubscribeしているので、どこに何のアプリが上がっているか把握できるわけです

26. これまでのPaaS Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus RDBなどバックエンドサービスへ North-Southのトラフィックが中心これまでのPaaSでは、インターネットから来るリクエストをアプリにルーティングする、北と南 (North-South)のトラフィックが中心でした。なので、 Messaging Busを使う仕組みは上手く機能していました

27. これからのPaaS Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus East-Westのトラフィックが多く発生 (Microservices) しかしMicroservices時代になり、コンテナ同士の通信 (East-West)のトラフィックが多く発生するようになりました。

28. いろいろ欲しくなる Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus mTLS Service Discovery Circuit Braker Traffic Control 結果として、相互TLSやサーキットブレーカー、サービスディスカバリ、トラフィックコントロールなどの仕組みが欲しくなってきました。既存の仕組みだけでは、徐々に実現が難しくなったわけです。

29. なんとかしたい

30. 選択肢既存のサービスメッシュ • Linkerd: 重い • Istio: オーケストレーターに依存しない • Conduit: k8sに特化自前 • ちゃんとメンテ出来る？ • 独自性出せる？ • 労力に見合った価値出せる？ということで、CFの開発チームは色々検討しました。他の仕組みの導入だけでなく、自前で開発も視野にいれて Pros/Consを検討した結果、Istioの選択がベストという結論に至ったようです。

31. Routing Tierの大変革 • Istio PilotとEnvoyを取り入れた新しいRouing Tierに https://docs.google.com/document/d/1VldkvgWPUh13o5RCNjSvzoPFhbY9BtLqBDdk2k0z9fw/ ということで、既存の Routing Tierを置き換える大胆な Proposalが出ています。

32. 利用例 $ cf push app-v1 コンテナを意識せずともソースコードをpush するだけでアプリが動く $ cf push app-v2 新バージョンをpush 既存のCFのワークフロー app-v1 app-v1 app-v2 まず既存のCFのフローで、古いバージョンと新しいバージョンのアプリをデプロイしておきます。コマンド2つだけ。楽ちんですね

33. 利用例 $ 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地獄ではなく、このシンプルさなんじゃないでしょうか

34. 利用例 $ 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な方法もとれるよう考えられているようです。

35. 進め方 • いきなりIstioに置き換えることはしない • 徐々に実装

36. Envoy sidecarの実装 (済) Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus Envoyのsidecarはもう実装されており、最新の CFで利用されています。

37. Router-App間のmTLS化(済) Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus RouterとApp間を相互TLSで通信する仕組みも、既に実装されています。

38. Container-to-Container用のDNS実装(済) Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus BOSH DNS Service Discoveryの機能もすでに実装済みです

39. Client-side load-balancingの実装 Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus

40. Edge RouterをEnvoyに Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus

41. Istio Pilotの実装 Diego cellDiego cell Diego cell Diego Brain Router Messaging Bus

42. ゴール Near-term - BookinfoデモがCFで動くこと - 外部からのリクエストを受け付けられる - CF内のアプリ間でルーティングできる - アプリ間で透過的な相互認証ができる - アプリ開発者がルーティングのルールを設定できる - 重み付けルーティングができる - HTTP/2のサポート Longer-term - 既存のCF Routingと同等機能のサポート - UDPサポート - User-provided TLS keypairのサポート - Mesh Egress

43. まとめ • IstioはMicroservicesを実現するにあたって必要なピースを提供してくれる • Kubernetesに限らず、Cloud Foundryにもガッツリと実装されていく • Microservicesやることが必須ではないが、プラットフォームはどんどんMicroservices向けの機能が追加されていく。 ○ これまで足かせになっていたポイントがプラットフォーム側で担保されるようになるので、改めてスケールするアーキテクチャ・組織を考え始めてもいいかも