Istio, Kubernetes and Cloud Foundry (修正版)
9 likes7,174 views
Container SIGで発表した資料です。 文字サイズを変えた修正版です
![[TL04] .NET 15 周年の今こそ考えるクラウドネイティブ アプリケーションと .NET の活用](https://cdn.slidesharecdn.com/ss_thumbnails/tl04-170614050632-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to Istio, Kubernetes and Cloud Foundry (修正版) (20)
![[Observability conference 2022/3/11] NewsPicks のプロダクト開発エンジニアが実践するスキルとしての SRE](https://cdn.slidesharecdn.com/ss_thumbnails/observabilityconference2022311newspickssre-220310143345-thumbnail.jpg?width=560&fit=bounds)
More from Kazuto Kusama (20)
Recently uploaded (11)
Istio, Kubernetes and Cloud Foundry (修正版)
- 2. Pivotal Japan - Solutions Architect Kazuto Kusama @jacopen
- 6. たとえば app A app B app CMicroservicesでは複数のアプリが上がって通信し合うワ ケですが、セキュリティは担保したいですよね。信頼できる アプリからのみ受け付けるようにしたい。 となると、相互TLSなどの仕組みが必要になってくる。
- 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 Canary release: (例) 重み付けをすることでトラフィックの10% を新アプリにFeature Flag: (例) 特定のcookieやヘッダを持つ 相手に対してのみ新アプリに これは、Microservicesに関わらず欲しい機能じゃないでしょう か
- 17. で、 地獄が加速 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が増えます。
- 21. を含めた のいいところ $ cf push app-v1 コンテナを意識せずとも ソースコードを するだけでアプリが動く アプリの運用に必要な機能 監視 ロギング メトリクス が最初から揃っている CFAR(PaaS)とk8s(CaaS)の大きな違いとして、PaaSは開発者のエクスペリエン スに特化しており、コンテナの存在を意識せずともアプリのデプロイができる点に あります。運用も色々揃ってます。 ※詳しくは私のスライドも参考にしてください
- 22. と、 がどう関係するのか
- 24. 先に結論 近い将来、 の 部分は に置き換えられ ?既にある の機能 ? によって実現される新機能 が、 の使い勝手を損なうこと無く利用できるようになります
- 26. 現在の の仕組み メッセージングバス から情報受け取り アプリを立ち上げると メッセージングバスに 通知 Diego Cellというコンポーネントが、自身 のもつコンテナの情報をMessaging Bus にPublishします。 Routerはその情報をSubscribeしている ので、どこに何のアプリが上がっているか 把握できるわけです
- 30. なんとかしたい
- 31. 選択肢 既存のサービスメッシュ ? 重い ? オーケストレーターに依存しない ? に特化 自前 ? ちゃんとメンテ出来る？ ? 独自性出せる？ ? 労力に見合った価値出せる？ CFの開発チームは色々検討しました。 他の仕組みの導入だけでなく、自前で開 発も視野にいれてPros/Consを検討した 結果、Istioの選択がベストという結論に 至ったようです。
- 32. の大変革 ? と を取り入れた 新しい に ということで、既存のRouting Tierを置き換 える大胆なProposalが出ています。
- 33. 利用例 $ cf push app-v1 コンテナを意識せずとも ソースコードを するだけでアプリが動く $ cf push 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 の を に割り当て の を に割り当て cfコマンドで重み付けを簡単設定 それぞれのアプリに対しての重み付けを行います。 --weightというパラメータを付け加えるだけです。YAML 不要でかなりシンプルですよね。 開発者が欲しいのはYAML地獄ではなく、このシンプル さなんじゃないでしょうか
- 35. 利用例 $ 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な 方法もとれるよう考えられているようで す。
- 36. 進め方 ? いきなり に置き換えることはしない ? 徐々に実装
- 38. 間の 化 済 RouterとApp間を相互TLSで通信する 仕組みも、既に実装されています。
- 39. 用の 実装 済 Service Discoveryの機能もすでに実 装済みです
- 40. の実装
- 41. を に
- 42. の実装
- 43. ゴール - デモが で動くこと 外部からのリクエストを受け付けられる 内のアプリ間でルーティングできる アプリ間で透過的な相互認証ができる アプリ開発者がルーティングのルールを設定できる 重み付けルーティングができる - のサポート - 既存の と同等機能のサポート - サポート - のサポート -
- 44. まとめ ? は を実現するにあたって必要な ピースを提供してくれる ? に限らず、 にもガッツリと 実装されていく ? やることが必須ではないが、プラットフォームはどんど ん 向けの機能が追加されていく。 ○ これまで足かせになっていたポイントがプラットフォーム側で担保されるようになるので、 改めてスケールするアーキテクチャ?組織を考え始めてもいいかも