VisionDrivenを絵に描いてみた。
VisionDrivenの本を読んで、面白かったので、右脳で捉えるために絵に描いてみた。
books.rakuten.co.jp
詳細は、ここに書かないので、本読んでください。考え方の違いを考えるのに非常に面白い本です。
もっとみんなで妄想しましょう。
Vision思考
妄想、知覚、組替、表現の4つのサイクルについての落書き。
Design思考
Vision思考との差を見直すために、Design思考の落書き。
[MEMO] katacodaでService Mesh with Istio: ver4 Simple Routings
IstioのRoutingを扱う
oc は openshiftのコマンドです。
実践
まず、前回の章と同じ状態から、コードを変更した新しいバージョンのdocker imageをkubernetesにistioctl経由でデプロイします。
$ docker build -t example/recommendation:v2 . $ oc apply -f <(istioctl kube-inject -f ../../kubernetes/Deployment-v2.yml) -n tutorial
で、podsを確認すると2つのrecommedationのバージョンが確認できます。
$ oc get pods -w NAME READY STATUS RESTARTS AGE customer-fc4cb47f9-cckgw 2/2 Running 0 15m preference-v1-6976458fcf-96qs6 2/2 Running 0 14m recommendation-v1-5857848d45-nb6q9 2/2 Running 0 13m recommendation-v2-7c98cb4d-7gsgd 2/2 Running 0 11m
customer->preference->recommendationと呼び出すマイクロサービスになってるので、customerにcurlアクセスすると、v1とv2に交互にアクセスしてるのがわかる。これは、kubernetesがデフォルトだとround robinでroutingするように設定されてるかららしい。
$ while true; do curl http://customer-tutorial.2886795293-80-kitek03.environments.katacoda.com; sleep .5; done customer => preference => recommendation v1 from '5857848d45-nb6q9': 2 customer => preference => recommendation v2 from '7c98cb4d-7gsgd': 3 customer => preference => recommendation v1 from '5857848d45-nb6q9': 3 customer => preference => recommendation v2 from '7c98cb4d-7gsgd': 4 customer => preference => recommendation v1 from '5857848d45-nb6q9': 4 customer => preference => recommendation v2 from '7c98cb4d-7gsgd': 5
version2のscaleを2にすると、2対1の割合でv2,v1にアクセスするようになったのが確認できる。
$ oc scale --replicas=2 deployment/recommendation-v2 $ while true; do curl http://customer-tutorial.2886795293-80-kitek03.environments.katacoda.com; sleep .5; done customer => preference => recommendation v2 from '7c98cb4d-qsdkx': 15 customer => preference => recommendation v1 from '5857848d45-nb6q9': 26 customer => preference => recommendation v2 from '7c98cb4d-7gsgd': 27 customer => preference => recommendation v2 from '7c98cb4d-qsdkx': 16 customer => preference => recommendation v1 from '5857848d45-nb6q9': 27 customer => preference => recommendation v2 from '7c98cb4d-7gsgd': 28 customer => preference => recommendation v2 from '7c98cb4d-qsdkx': 17 customer => preference => recommendation v1 from '5857848d45-nb6q9': 28
Yamlでコントロールする
ただ、大半の用途だと、手動でアクセスの分岐をコントロールしたいはずなので、それをコントロールするためにDestinationRuleとVertualServiceの2つを設定する。
まずはBlueGreenの例かな。
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: recommendation spec: host: recommendation subsets: - labels: version: v1 name: version-v1 - labels: version: v2 name: version-v2 ---
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: recommendation spec: hosts: - recommendation http: - route: - destination: host: recommendation subset: version-v2 weight: 100 ---
$ istioctl create -f ~/projects/istio-tutorial/istiofiles/destination-rule-recommendation-v1-v2.yml -n tutorial $ istioctl create -f ~/projects/istio-tutorial/istiofiles/virtual-service-recommendation-v2.yml -n tutorial
これで、recommendationへのアクセスが100% version-v2に行くことが確認できる。
ここらへんのコマンドで、現在のvirtualServiceの確認ができる。
$ istioctl get virtualservice $ istioctl get virtualservice recommendation -o yaml -n tutorial
これがカナリーリリースを行う場合。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: recommendation spec: hosts: - recommendation http: - route: - destination: host: recommendation subset: version-v1 weight: 90 - destination: host: recommendation subset: version-v2 weight: 10 ---
こういう感じで、routingのコントロールができるみたい。
見た感じなんとなくやりたいことはわかるが、違いのわかる男になるために、ちょっと公式で勉強する。
DestinationRule
https://istio.io/docs/reference/config/networking/v1alpha3/destination-rule/
[簡易翻訳]
- host - 簡単に言うとKubernetesに登録されてるService 名を置く。ただ、kubernetesの"reviews.default.svc.cluster.local”のような、省略しない書き方のほうが将来のミスを避けるための好まれるみたい。
- trafficPolicy - これらを設定するところ(load balancing policy, connection pool sizes, outlier detection)。今回の設定ファイルには書かれてない。
- subsets - ここに、各バージョンの管理を書くみたい。で、それぞれのsubesetでTraficPolicyをかける。その場合、servicelevelの設定は、上書きされる。
trafficPolicy: loadBalancer: simple: ROUND_ROBIN
ハッシュ値を利用してbalancing。ユーザのCookieを利用する。
trafficPolicy: loadBalancer: consistentHash: httpCookie: name: user ttl: 0s
VirtualService
traffic routingに影響する設定らしい。
[翻訳] "VirtualServiceは指定したホストへのアクセスが有った場合の、複数のtraffic routingルールの定義になる。"。
そういえば、IngressGatewayでも出てきたな。
[翻訳] 例えば、下記のKubernetes上の例だと、すべてのreviews serviceへのHTTPアクセスは“version: v1”にルートされる。そして、/wpcatalog/ or /consumercatalog/だと、 /newcatalogに上書きされた上で“version: v2”にルートされる。
で、上が先に評価される(たしか)なので、指定のURLの場合、“version: v1に転送されないはず。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews-route spec: hosts: - reviews.prod.svc.cluster.local http: - name: "reviews-v2-routes" match: - uri: prefix: "/wpcatalog" - uri: prefix: "/consumercatalog" rewrite: uri: "/newcatalog" route: - destination: host: reviews.prod.svc.cluster.local subset: v2 - name: "reviews-v1-route" route: - destination: host: reviews.prod.svc.cluster.local subset: v1
katacodaでService Mesh with Istio: ver3 Monitoring and Tracing
Monitoring and Tracing
Prometheus と Grafana使ってるみたい。 っというか、Kubernetes周りの3rd Partyはこの2つをけっこう使ってるケースを見る。オートスケールとかPrometheusにメトリクスもたせて行ってる実装をよく目にする。
Code
実際にyamlファイルを作成し、Prometheusにmetricsを反映させることができるみたいやな。
istioctl create -f hogehoge.yml -n istio-system
openshiftだと、このコマンドでアクセスするためのURLを取得できるみたい。
oc get routes -n istio-system
kubernetesだとどげんすっとやろ。
https://istio.io/docs/tasks/telemetry/metrics/using-istio-dashboard/
ここ見たらわかりそう。
kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3000:3000 &
このコマンドのあとに、このURLにアクセスすると確認できた。たぶん、kubectlでポートを割り当てて、フォワードしてる。 http://localhost:3000/d/-vJFVqdWk/istio-mesh-dashboard?orgId=1
で、ちゃんと、メトリクスが追加されているか確認。
Tips
- kubectl port-forward どうやら、このコマンドは kubectlのローカルホストにフォワードする機能みたい。
使い方 Use Port Forwarding to Access Applications in a Cluster - Kubernetes
ちょっと詳細 Kubectl Reference Docs
あと、どうやって、このport forward止めるんだろうって、思ってたらどうやら、別に子プロセスをセッションに作ってるみたいだから、それをkillすればOK
$ jobs [1]+ Running kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3000:3000 & $ kill -9 %1 $ jobs [1]+ Killed: 9 kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3000:3000
Training
OpenTracingとJaegerを利用してるみたい。これは使ったことない。 というか、ビッグデータ周りを最近やってて、このMicroServiceのトレース系をあまり触る機会がなかったな。 OpenTracingは非ベンダ依存のAPIのフレームワークらしい、でJaegerはTrace用のデータを収集したり、保存、可視化したりするツール。でJaegerはOpenTracing を利用して、MicroServiceからデータの収集をしてるみたい。Zipkinを参考にJaegerが作られたみたい。何が違うのかは、別途勉強。
とりあえず、書いてあることを見ると、Istioが自動的にdataを集めて、Jaegerに送信するみたい。なので、アプリはOpenTracingとかJaegerを気にしなくて良い。
とりあえず、確認結果見れたことのキャプチャを貼っておく。 非常に便利だと思った。Zipkinと比べてみたいなぁ。なんとなく、Jaegerのほうがシンプルな感じがする。今度、勉強しよう。
Search
一つのServiceのアクセス結果リストページ。全体の結果を俯瞰的に見るときに役に立つ。
Detail
一つのクエリの詳細ページ。極端に気になるものがあった場合のボトルネックを探せそう。
Dependencies
各APIのお互いの利用回数とか、依存関係も一目瞭然!
IstioのIngressGatewayの検証
[MEMO] katacodaでService Mesh with Istio: ver2 Istioctl - だいごろうのブログ こっちのブログポストで気になったので、 ingress gatewayを試してみようと思います。環境作成を前のブログを参考にしてください。
Ingress Gateway
KubernetesのIngress Controllerと似たような機能を Istioとかで利用できるようにするのがIngress Gatewayっぽい。
とりあえず、ここを理解してみよう。 Istio / Ingress Gateways
Istio on Minikube
Istio / Minikube どうやら、デフォルトだとメモリやCPUが全然足りないみたいなので、増やす。最初、これをしてなくて、全然、podが起動しなくて、困った。 とりあえず、メモリとCPUを倍に増やしてみる。(まだ、足りないかも)あと、minikubeのデフォルトのVMがいっぱいいっぱいになってきたので、profile変えてみる。
minikube start --memory=4096 --cpus=4 -p istio
後で気づいたが、tunnelでistioにLoadBalancerを提供できるみたい。 後日検証。
sudo minikube tunnel
Istioの確認
kubectl get svc istio-ingressgateway -n istio-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 10.110.94.62 <pending> 15020:32200/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:32445/TCP,15030:30505/TCP,15031:30605/TCP,15032:31662/TCP,15443:30531/TCP 7d
このEXTERNAL-IPがNoneやpendingの場合は、NodePortでアクセスしてくれって書いてあるな。たぶん、LoadBalancer立ててないのと、minikubeのせいで、pendingになってんのかな。 external load balancer for the ingress gateway
がないと、あかんっぽいな。
minikube + nodeportの場合は、IPとポートをこんな感じで取得
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}') export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}') export INGRESS_HOST=$(minikube ip -p istio)
公式に沿って、istio GatewayとVirtualService立てる
Gateway
kubectl apply -n istio-tutorial -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: httpbin-gateway namespace: istio-tutorial spec: selector: istio: ingressgateway # use Istio default gateway implementation servers: - port: number: 80 name: http protocol: HTTP hosts: - "istio.tutorial.com" EOF
VirtualService
kubectl apply -n istio-tutorial -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: httpbin spec: hosts: - "istio.tutorial.com" gateways: - httpbin-gateway http: - match: - uri: prefix: / route: - destination: port: number: 8080 host: customer EOF
確認
# ちゃんと設定できているかを確認 curl -I -HHost:istio.tutorial.com http://$INGRESS_HOST:$INGRESS_PORT/ -v # アクセスを確認 kubectl logs pod/customer-59975dcff6-jwc7c -n istio-tutorial --all-containers=true -f
Ingress gateway と ingress resources
Ingress gateway と ingress resourcesの違いをちゃんと理解したい。今、認識ているところだと、ingress gatewayを使うと、Istioの旨味をGatewayでも利用できる点と、 既存のingress resourcesだとhttp/httpsしか、ハンドルできないんじゃないかな。
これも後でちゃんとよむ。 Ingress - Kubernetes
感想
思ったとおり、動いた!でも、Istioのインストールのときに、なぜか数分間いくつかのpodがうまく起動できなかったり、ちょっとハマった。まだ、わかってない点がおおいなぁ。kubernetes のingressでも思ったが、簡単に使える点は良い。理解しなければいけないことは多いが、便利。
[MEMO] katacodaでService Mesh with Istio: ver2 Istioctl
istioctl
どうやらこのコマンドがistioの味噌みたい。 この章ではistioctl kube-injectをメインに勉強。
Deploy.yamlにkube-injectコマンドすることで、SideCarなどの設定を自動で入れてくれるみたい。
istioctl kube-inject -f {YAML}
こんな感じでおしゃれに渡してる。
kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n namespace
Kubernetesでやってみる
Katacodaの中身がocコマンドつまりredhatのopenshiftなので、minikube立ててローカルでkubernetesでやってみた。
とりあえず、Istioをkubenetesにapplyとistioctlインストールしておく
curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.2.2 sh - cd istio-1.2.2 export PATH=$PWD/bin:$PATH kubectl create namespace istio-system for i in install/kubernetes/helm/istio-init/files/crd*yaml; do kubectl apply -n istio-system -f $i; done kubectl apply -f install/kubernetes/istio-demo.yaml
# 準備 git clone https://github.com/redhat-developer-demos/istio-tutorial/ minikube start kubectl create namespace istio-tutorial cd istio-tutorial cd customer/kubernetes/ ## istioctl kube-injectを確かめておこう istioctl kube-inject -f Deployment.yml ## kubectlにappyする kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n istio-tutorial kubectl get all -n istio-tutorial less kubernetes/Deployment.yml # 既存がClusterIPで外部から見れないので、NodePortも作る cp Service.yml Servicenp.yml vi Servicenp.yml diff Service.yml Servicenp.yml 4c4 < name: customer --- > name: customernp 6c6 < app: customer --- > app: customernp 7a8 > type: NodePort kubectl apply -f Service.yml -n istio-tutorial kubectl apply -f Servicenp.yml -n istio-tutorial ## アクセスしたいので, ip portを調べる kubectl get service/customernp -n istio-tutorial -owide # nodeのIPがわからんかったから、 cluster-infoから引っ張ってくる kubectl cluster-info curl https://192.168.99.100:32318 ## ほかもapply ## curlのレスポンスが変わっていくのが確認できる cd ../../preference/kubernetes/ kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n istio-tutorial kubectl apply -f Service.yml -n istio-tutorial curl http://192.168.99.100:32318 cd ../../recommendation/kubernetes/ kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n istio-tutorial kubectl apply -f Service.yml -n istio-tutorial curl http://192.168.99.100:32318
最終的にはこんな感じ
kubectl get all -n istio-tutorial NAME READY STATUS RESTARTS AGE pod/customer-59975dcff6-7k8rr 2/2 Running 0 27m pod/preference-v1-8578c48ff-mjhln 2/2 Running 0 9m7s pod/recommendation-v1-85474b59d5-5hhg4 2/2 Running 1 7m15s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/customer ClusterIP 10.106.206.127 <none> 8080/TCP 19m service/customernp NodePort 10.111.254.169 <none> 8080:32318/TCP 20m service/preference ClusterIP 10.102.211.153 <none> 8080/TCP 8m57s service/recommendation ClusterIP 10.105.191.131 <none> 8080/TCP 7m11s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/customer 1/1 1 1 27m deployment.apps/preference-v1 1/1 1 1 9m7s deployment.apps/recommendation-v1 1/1 1 1 7m15s NAME DESIRED CURRENT READY AGE replicaset.apps/customer-59975dcff6 1 1 1 27m replicaset.apps/preference-v1-8578c48ff 1 1 1 9m7s replicaset.apps/recommendation-v1-85474b59d5 1 1 1 7m15s
どんな感じで、コードの方は定義されてんやろう。どうやって、istioを利用してるんだろう。
customer -> preference
で名前解決してるところはどうやら単純に、preferenceをhostとして指定するだけみたい。
preferences.api.url=http://preference:8080
同じnamespaceのserviceにservice名でアクセスできる感じかな。あとでもっと理解する必要ありそう。ただ、docker-composeと同じように名前をつけれるので、ローカルではdocker-composeで開発して、kubernetesデプロイ時にはistioに名前解決させるで良さそう。
ingress gateway
よく考えたら、serviceのnodeport使わなくても、 ingress gatewayからアクセスとかできるんじゃないかな。ちょっと検証してみよう。ただ、長くなってきたから、別のブログポストにまとめます。
まとめ
istioのサポートがアツい。kubernetesへの導入の簡単さ、違和感なくkubernetesを使えてる感じ。すごい。
[更新中] Docker初心者向けコンテンツまとめ
ゴール
社内でDockerを勉強した人がいたので、ちょっと、情報をまとめてみた。 今(2019/08/01)、僕の認識してるところだと、大きな障壁が英語である。DockerとかはVMとの違いは何かなどの考え方の違いの理解が多く必要だと思うので、英語に慣れていない人だとハンズオン系のものが足りなく感じるので、このページで、どこらへんを見て勉強すれば良いかの目印を作れればと思う。 このページは、Docker自体については、記述しないし、今現在の情報を載せるつもりです。こういうのもあるよってあれば、教えてほしいです。
ハンズオン系
英語
katacoda
今の所、一番好き。オンラインでできるので、dockerのインストールもいらないし、どんな環境からもやりやすい。Katacoda内にkubernetesもあるし、幅広いコンテンツもあるので、 www.katacoda.com
learndocker
VideoとQuizzeに分かれていて、理解度を確認しながら進めるみたい。 githubのアカウント連携を求められる。 learndocker.online
sample code
Dockerの公式。サンプルコードがたくさんあるし、Tutorial labsのチャプターで自分のユースケースに合わせて、勉強すれば感覚がつかめるんじゃなかろうか。 docs.docker.com
日本語
入門 Docker
パット見た限りであるが、初心者向けには良さそうでさる。絵を使って概念の説明と、利用コマンド例が入ってる。資料にそって、練習するだけで基本は身につきそう。 y-ohgi.com
Video
英語
youtube
12分で、Dockerの基本を紹介してる。初めてだときついかも。 Learn Docker in 12 Minutes 🐳 - YouTube
udemy
Udemy。Docker,Kubernetesまでをカバーしており、今の所一番人気っぽい?1万円くらい。 https://www.udemy.com/docker-and-kubernetes-the-complete-guide/
日本語
udemy
Udemy。1万円くらいするが、日本語で教えてくれると思うと安い。 https://www.udemy.com/docker-k/
他の紹介サイト
さすが、英語だと大量にコンテンツある hackr.io
引き続き更新していきます。2019/08/01
[MEMO] katacodaでService Mesh with Istio: ver1 Istio Introduction
前回までKubenetesをやってたんですが、続いて、ServiceMeshも正しく理解したくて今回から別のコースをやって行きたいと思います。
勝手に名言「正しい判断は正しい知識から。」( ー`дー´)キリッ
公式も後で読もう。 istio.io
Istion/ServiceMesh Introduction
ServiceMeshはMicroServiceのネットワークあたりの用語としてよく使われる。 MicroServiceが増えてくるとdiscovery, load balancing, failure recovery, metrics, and monitoringあたりが必要かつ難しくなってくる。また、ここらへんも求められちゃう A/B testing, canary releases, rate limiting, access control, and end-to-end authentication。
Istio
Istioはservice meshの振る舞いのInsightや運用管理を可能とする。
- traffic管理 : Service感の通信の管理
- 管理能力 : どのpodがどのservice使ってんの
- Policyの施行 : serviceを超えてpolicyをひとまとめに管理できる的な? Meshの設定でそれを管理するので、全体でフェアなリソース管理になるって感じかな
- Serviceのidentityとセキュリティ : サービスの認証あるから、セキュリティも担保しやすい。てきな
Istioは最初Kubernetesのために作られたが今はMesosなどにも対応してるし、onPre,Cloudどちらもおーけー。あと、Policyなどはカスタマイズ可能で、ACLs, logging, monitoring, quotas, auditing ここらへんを自由に付け替え可能らしい。
DataPlane / ControlePlane
https://istio.io/docs/concepts/what-is-istio/#architecture
data plane
intelligent proxies (Envoy) のセットで、SideCarとしてデプロイされる。MicroService間のネットワークをコントロール。proxyの仲介を行う。Mixerから設定を読み取るっぽい。 (TODO SideCar勉強しないと。)
control plane
control planeはproxyの管理を行う。Mixerの調整を行う。
Envoy
Envoyはhigh-performance proxyです。PodのSideCar としてデプロイされるDataPlane。 Pilotから設定を受け取りServiceのインバウンド・アウトバウンド両方のTrafficの仲介・管理・監視を行うっぽい。
Mixer
MixerはPlatform非依存のコンポーネント。ServiceMeshの中で、アクセスコントロールとポリシーの利用を強制する役割を持つ。Proxy(Envoy)からそれらの設定へのアクセスを一任する MixerはControl planeの一つのAPIでProxyの設定の保持とData Planeへの公開を担当してるみたい。
Pilot
Pilot はEnvoySidecar向けのサービスディスカバリ, intelligent routingのためのTraffic管理能力を提供してる。まぁ、つまり、それらの設定をproxy(Envoy)に配布する役割 Pilotを使うことで、Trafficの管理ができる。5%はこのサービスに送るとかCanaryリリースが可能。特定のTrafficはこっちのバージョンに送るとか。
Citadel
Citadelはサービス間やユーザの認証とCredential管理を行う。Citadelを利用することで、ネットワークの制御でなく、Serviceの認証による管理が可能になる。的な。