Weitere ähnliche Inhalte
Ähnlich wie Istio, Kubernetes and Cloud Foundry (修正版) (20)
Mehr von Kazuto Kusama (20)
Istio, Kubernetes and Cloud Foundry (修正版)
- 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は開発者のエクスペリエン
スに特化しており、コンテナの存在を意識せずともアプリのデプロイができる点に
あります。運用も色々揃ってます。
※詳しくは私のスライドも参考にしてください
- 24. 先に結論
近い将来、 の 部分は に置き換えられ
・既にある の機能
・ によって実現される新機能
が、 の使い勝手を損なうこと無く利用できるようになります
- 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な
方法もとれるよう考えられているようで
す。
- 38. 間の 化 済 RouterとApp間を相互TLSで通信する
仕組みも、既に実装されています。
- 44. まとめ
• は を実現するにあたって必要な
ピースを提供してくれる
• に限らず、 にもガッツリと
実装されていく
• やることが必須ではないが、プラットフォームはどんど
ん 向けの機能が追加されていく。
○ これまで足かせになっていたポイントがプラットフォーム側で担保されるようになるので、
改めてスケールするアーキテクチャ・組織を考え始めてもいいかも