Istioにはリクエストパスごとに割り振るサービスを設定することができます。
例えば、/api/v1/hoge はAのサービスに、/api/v2/fuga はBのサービスに割り振るといった設定です。

これらの機能について、前回の記事『 helmパッケージ化されたアプリをKubernetes+Istioを使って公開する』で作った環境とhelmパッケージを使って実現方法をまとめていきます。

まず前回のおさらいですが、今の所全てのリクエストがfoolish-penguin-sampleか、peeking-rabbit-sampleのサービスに流れる設定になっています。

for i in `seq 0 9` ; do curl 127.0.0.1.xip.io ; done

もちろんこれは/hoge/fugaに対するアクセスにも適用されます。

今回はこの/hoge/配下のに対するリクエストを他のサービスに割り振る設定をしていきます。

シンプルなHTTPルーティングの実現

HTTPルーティングは、VirtualServiceのリソースを使って設定します。

まずはルーティング先のServiceを作ります。
前回作成したsampleのチャートが含まれているフォルダに移動し、新規にデプロイします。
今回も説明の都合上、リリース名をangry-swanに固定します。

cd ./sample
helm install --name=angry-swan .

次にsample-gatewayのフォルダに移動し、VirtualServerに設定を書き加えます。

cd ../sample-gateway
vi templates/virtualservice.yaml
vi Chart.yaml
git diff
git add .
git commit -m "Added http routing for angry-swan."
git tag 0.2.0

書き加えた設定を反映させるため、sample-gatewayをアップグレードします

helm upgrade exciting-lemur .

これで期待通りのルーティングになっているか確認していきます。
確認には前回同様のcurlに加えて、今回確認したい/hoge/fugaに対するリクエストを実行し、さらに無関係な/mokeにリクエストを実行して確認していきます。

for i in `seq 0 9` ; do curl 127.0.0.1.xip.io ; done
curl 127.0.0.1.xip.io/hoge/fuga
curl 127.0.0.1.xip.io/moke

結果の通り、/へのリクエストはfoolish-penguin-sampleかpeeking-rabbit-sampleに、/hoge/fugaはangry-swan-sampleに、/mokeは/のマッチが適用されてfoolish-penguin-sampleかpeeking-rabbit-sampleに振り分けられている事が確認できました。

ポッドに対するログも見ていきます。

export POD_NAME=$(kubectl get pods --namespace default -l "app=sample,release=angry-swan" -o jsonpath="{.items[0].metadata.name}")
kubectl logs -f $POD_NAME sample | grep -v kube-probe

ログを読むとangry-swan-sampleからのリクエストがそのまま/hoge/fugaに対して実行されていることが確認できます。
このログのフォローもCtrl+cで終了する事ができます。

パスのリライトを含んだHTTPルーティング

サービスに対してリクエストをルーティングする際、パスを書き換えて実行する機能がIstioには備わっています。
例えば、/api/hoge/v1/fugaはAのサービスにルーティングするけど、その際にリクエストパスを/api/fugaに変更してサービスに渡すといった事ができるようになります。

今回は例の通り、/api/hoge/v1/fugaに対するリクエストをangry-swan-sampleに、パスを/api/fugaに変更しつつ渡す設定をします。

リライトの設定はVirtualServiceに対して入れていきます。

vi templates/virtualservice.yaml
vi Chart.yaml
git diff
git add .
git commit -m "Added path rewrite from '/api/hoge/v1/fuga' to '/api/fuga'."
git tag 0.2.1

その後書き加えた設定を反映させるため、sample-gatewayをアップグレードします

helm upgrade exciting-lemur .

実際にリクエストを投げてangry-swan-sampleにリクエストが流れていることを確認します。

curl 127.0.0.1.xip.io/api/hoge/v1/fuga

先ほどと同様にポッドに対するログも見ていきます。

export POD_NAME=$(kubectl get pods --namespace default -l "app=sample,release=angry-swan" -o jsonpath="{.items[0].metadata.name}")
kubectl logs -f $POD_NAME sample | grep -v kube-probe

ログの最後の一行（最新のリクエストに対するログ）を読むとリクエストパスがリライトされ、/api/fugaにリクエストが飛んでいる事が確認できます。

加えてその配下に対するアクセスに対してもリライトされた後に実行されます。

curl 127.0.0.1.xip.io/api/hoge/v1/fuga/aaaa
kubectl logs -f $POD_NAME sample | grep -v kube-probe

上記の例では/api/hoge/v1/fuga/aaaに対するリクエストがリライトされ、/api/fuga/aaaに飛んでいる事が確認できます。

今回は以上のように、Istioでリクエストパスを使ったHTTPルーティングを設定し、動きを確認する事ができました。