IstioのIntelligent-routingを公式のデモにそって確認した。
今回はdestinationruleの変更とHTTPのヘッダーベースのルーティングを確認。
目次
環境
前回の記事の続きで、公式のデモアプリケーションが動作済みを前提とする。
$ kubectl get node -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
k8s-master1 Ready master 34d v1.11.3 192.168.110.246 <none> Ubuntu 16.04.5 LTS 4.4.0-72-generic docker://17.3.2
k8s-master2 Ready master 34d v1.11.3 192.168.110.248 <none> Ubuntu 16.04.5 LTS 4.4.0-72-generic docker://17.3.2
k8s-master3 Ready master 34d v1.11.3 192.168.110.244 <none> Ubuntu 16.04.5 LTS 4.4.0-72-generic docker://17.3.2
k8s-node1 Ready <none> 34d v1.11.3 192.168.110.243 <none> Ubuntu 16.04.5 LTS 4.4.0-72-generic docker://17.3.2
k8s-node2 Ready <none> 34d v1.11.3 192.168.110.241 <none> Ubuntu 16.04.5 LTS 4.4.0-72-generic docker://17.3.2
k8s-node3 Ready <none> 34d v1.11.3 192.168.110.247 <none> Ubuntu 16.04.5 LTS 4.4.0-72-generic docker://17.3.2
$
$ kubectl -n istio-system get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
istio-citadel-8545986b5c-qnpt6 1/1 Running 1 1d 10.244.5.62 k8s-node3 <none>
istio-cleanup-secrets-2srbf 0/1 Completed 0 1d 10.244.4.15 k8s-node2 <none>
istio-egressgateway-f449f844-d7mf6 1/1 Running 1 1d 10.244.4.22 k8s-node2 <none>
istio-galley-5c77f544cc-tl428 1/1 Running 1 1d 10.244.5.61 k8s-node3 <none>
istio-ingressgateway-7fc4cdbfc7-gdkpm 1/1 Running 1 1d 10.244.5.60 k8s-node3 <none>
istio-pilot-7974d67fcc-clhlt 2/2 Running 2 1d 10.244.3.23 k8s-node1 <none>
istio-policy-6bc68c8bcb-56zw2 2/2 Running 3 1d 10.244.5.63 k8s-node3 <none>
istio-security-post-install-8dppl 0/1 Completed 0 1d 10.244.3.20 k8s-node1 <none>
istio-sidecar-injector-74cd5c9565-cxc29 1/1 Running 1 1d 10.244.4.24 k8s-node2 <none>
istio-telemetry-7658f85655-5kpwb 2/2 Running 3 1d 10.244.4.20 k8s-node2 <none>
prometheus-554b5cc795-tbkjl 1/1 Running 1 1d 10.244.4.23 k8s-node2 <none>
$
$ kubectl -n istio-demo get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
details-v1-64f56d694d-znxpw 2/2 Running 0 23h 10.244.5.65 k8s-node3 <none>
productpage-v1-b8cf99cd-ghl92 2/2 Running 0 23h 10.244.5.67 k8s-node3 <none>
ratings-v1-8546767f5b-6vwrt 2/2 Running 0 23h 10.244.4.26 k8s-node2 <none>
reviews-v1-546d9f77ff-8mrmk 2/2 Running 0 23h 10.244.5.66 k8s-node3 <none>
reviews-v2-8fc76589f-4n5tl 2/2 Running 0 23h 10.244.4.27 k8s-node2 <none>
reviews-v3-7fdf5c754c-d82vc 2/2 Running 0 23h 10.244.3.25 k8s-node1 <none>
IstioのIntelligent Routing
アプリケーショントラッフィクのルーティングを提供する。
– HTTPリクエストヘッダーをベースにサービスのルーティングを行う
– 意図的に遅延やエラーを発生させる
– Weightベースでリクエストをロードバランスする
– クラスタに入るトラフィックや出るトラフィックの制御
– トラフィックのミラーリング
上記のような機能が提供されている。
公式のデモ
公式のデモをベースに機能を確認する。
設定確認
現在設定されているPod、Service、Endpointsを確認する。
$ kubectl -n istio-demo get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
details-v1-64f56d694d-znxpw 2/2 Running 0 23h 10.244.5.65 k8s-node3 <none>
productpage-v1-b8cf99cd-ghl92 2/2 Running 0 23h 10.244.5.67 k8s-node3 <none>
ratings-v1-8546767f5b-6vwrt 2/2 Running 0 23h 10.244.4.26 k8s-node2 <none>
reviews-v1-546d9f77ff-8mrmk 2/2 Running 0 23h 10.244.5.66 k8s-node3 <none>
reviews-v2-8fc76589f-4n5tl 2/2 Running 0 23h 10.244.4.27 k8s-node2 <none>
reviews-v3-7fdf5c754c-d82vc 2/2 Running 0 23h 10.244.3.25 k8s-node1 <none>
$ kubectl -n istio-demo get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
details ClusterIP 10.99.29.8 <none> 9080/TCP 23h
productpage ClusterIP 10.108.51.237 <none> 9080/TCP 23h
ratings ClusterIP 10.111.240.211 <none> 9080/TCP 23h
reviews ClusterIP 10.96.155.38 <none> 9080/TCP 23h
$ kubectl -n istio-demo get endpoints
NAME ENDPOINTS AGE
details 10.244.5.65:9080 23h
productpage 10.244.5.67:9080 23h
ratings 10.244.4.26:9080 23h
reviews 10.244.3.25:9080,10.244.4.27:9080,10.244.5.66:9080 23h
/productpageにアクセスするとratingsやreviewsから情報を取得するようなアプリケーションになっている。
上記出力から、reviewsというServiceにアクセスするとreviews-v1、reviews-v2またはreviews-v3にアクセスが分散される。
前回同様IngressGatewayを通して、bookinfoアプリケーションにアクセスして更新をかけると、下記のように星が赤いとき、黒いとき、ないときの3つの異なるページが現れる。
review-v1の画面
review-v2の画面
review-v3の画面
内部で、reviewsのv1、v2、v3に振り分けられているためにこの事象が発生する。
次にIstioを使ってすべてのアクセスをv1のみに振り分ける。
サービスのルーティング
まずは、振り分け先のリソースとして、DestinationRuleを定義する。
$ kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml
先程のyamlでは、ラベルを用いて振り分け先の定義をしていることが下記を見るとわかる。
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v3
labels:
version: v3
次に、reviewsへアクセスしたときどのDestinationRuleに振り分けるかというVirtualServiceの定義を行う。
最初は全てv1に振り分けるものを設定。
$ kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml
reviewに注目すると、reviewsへアクセスしたとき、destinationruleで定義されたreviewsのv1に振りわける設定をしている。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
これにより、先ほどと同様にブラウザからアプリケーションへアクセスするといつも星がないv1ページが表示される。
試しにdestinationをreviewのv2にするといつもv2になることがわかる。
下記のようなvs-reviews-v2.yamlを作成
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v2
設定を適用する。
$ kubectl apply -f vs-reviews-v2.yaml
これにより、黒い星のreview-v2ページが常に表示される。
設定を確認する。
$ kubectl get virtualservice reviews -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"networking.istio.io/v1alpha3","kind":"VirtualService","metadata":{"annotations":{},"name":"reviews","namespace":"istio-demo"},"spec":{"hosts":["reviews"],"http":[{"route":[{"destination":{"host":"reviews","subset":"v2"}}]}]}}
creationTimestamp: 2018-10-17T00:40:29Z
generation: 1
name: reviews
namespace: istio-demo
resourceVersion: "6185386"
selfLink: /apis/networking.istio.io/v1alpha3/namespaces/istio-demo/virtualservices/reviews
uid: 3ef3f21a-d1a5-11e8-957b-fa163eda9a66
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v2
$ kubectl get destinationrule reviews -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"networking.istio.io/v1alpha3","kind":"DestinationRule","metadata":{"annotations":{},"name":"reviews","namespace":"istio-demo"},"spec":{"host":"reviews","subsets":[{"labels":{"version":"v1"},"name":"v1"},{"labels":{"version":"v2"},"name":"v2"},{"labels":{"version":"v3"},"name":"v3"}]}}
creationTimestamp: 2018-10-17T00:37:24Z
generation: 1
name: reviews
namespace: istio-demo
resourceVersion: "6183206"
selfLink: /apis/networking.istio.io/v1alpha3/namespaces/istio-demo/destinationrules/reviews
uid: d115aea4-d1a4-11e8-aff0-fa163eac9a21
spec:
host: reviews
subsets:
- labels:
version: v1
name: v1
- labels:
version: v2
name: v2
- labels:
version: v3
name: v3
$
HTTPリクエストベースのルーティング
続いて、HTTPのリクエストヘッダーをベースにルーティングを行う。
公式のデモでは、end-userフィールドのヘッダーがjasonのときだけv2にルーティングするものが紹介されているので試す。
kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml
下記のようにjasonでログインする。
すると、v2のページが表示されるようになる。
このような機能は純粋なkubernetesにはなく。ヘッダーを利用して内部向けサービスや外部向けサービスのデータをルーティングすることも可能。