Weitere ähnliche Inhalte Ähnlich wie Istio, Kubernetes and Cloud Foundry (20) Mehr von Kazuto Kusama (20) Istio, Kubernetes and Cloud Foundry1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0
Istio, Kubernetes and
Cloud Foundry
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の詳細までは踏み込みません。
興味のある方は、是非これらリンクを参考にして
ください。
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は開
発者のエクスペリエンスに特化しており、コンテナの存在を
意識せずともアプリのデプロイができる点にあります。運用
も色々揃ってます。
※詳しくは私のスライドも参考にしてください
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やサーキットブレーカー、サービス
ディスカバリ、トラフィックコントロールなどの仕組みが欲し
くなってきました。
既存の仕組みだけでは、徐々に実現が難しくなったわけで
す。
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で利
用されています。
45. Transforming How The World Builds Software
© Copyright 2017 Pivotal Software, Inc. All rights Reserved.