3.7. トラフィック管理
こちらは、サポートされなくなった Red Hat OpenShift Service Mesh リリースのドキュメントです。
Service Mesh バージョン 1.0 および 1.1 コントロールプレーンはサポートされなくなりました。Service Mesh コントロールプレーンのアップグレードの詳細は、Service Mesh の アップグレード を参照してください。
特定の Red Hat OpenShift Service Mesh リリースのサポートステータスは、製品ライフサイクルページ を参照してください。
Red Hat OpenShift Service Mesh のサービス間のトラフィックのフローおよび API 呼び出しを制御できます。たとえば、Service Mesh の一部のサービスはメッシュ内で通信する必要があり、他のサービスは非表示にする必要がある場合があります。トラフィックを管理して、特定のバックエンドサービスを非表示にし、サービスを公開し、テストまたはバージョン管理デプロイメントを作成し、または一連のサービスのセキュリティーの層を追加します。
3.7.1. ゲートウェイの使用
ゲートウェイを使用してメッシュの受信トラフィックおよび送信トラフィックを管理することで、メッシュに入るか、メッシュを出るトラフィックを指定できます。ゲートウェイ設定は、サービスワークロードとともに実行するサイドカー Envoy プロキシーではなく、メッシュのエッジで実行するスタンドアロン Envoy プロキシーに適用されます。
Kubernetes Ingress API などのシステムに入るトラフィックを制御する他のメカニズムとは異なり、Red Hat OpenShift Service Mesh ゲートウェイではトラフィックのルーティングの機能および柔軟性を最大限に利用します。
Red Hat OpenShift Service Mesh ゲートウェイリソースは、Red Hat OpenShift Service Mesh TLS 設定を公開して設定するポートなど、レイヤー 4-6 の負荷分散プロパティーを使用できます。アプリケーション層のトラフィックルーティング (L7) を同じ API リソースに追加する代わりに、通常の Red Hat OpenShift Service Mesh 仮想サービスをゲートウェイにバインドし、Service Mesh 内の他のデータプレーントラフィックのようにゲートウェイトラフィックを管理できます。
ゲートウェイは ingress トラフィックの管理に主に使用されますが、egress ゲートウェイを設定することもできます。egress ゲートウェイを使用すると、メッシュからのトラフィック専用の終了ノードを設定できます。これにより、Service Mesh にセキュリティー制御を追加することで、外部ネットワークにアクセスできるサービスを制限できます。また、ゲートウェイを使用して完全に内部のプロキシーを設定することもできます。
ゲートウェイの例
ゲートウェイリソースは、着信または発信 HTTP/TCP 接続を受信するメッシュのエッジで動作するロードバランサーを表します。この仕様には、公開する必要のあるポートのセット、使用するプロトコルのタイプ、ロードバランサー用の SNI 設定などが記述されています。
以下の例は、外部 HTTPS Ingress トラフィックのゲートウェイ設定を示しています。
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: ext-host-gwy spec: selector: istio: ingressgateway # use istio default controller servers: - port: number: 443 name: https protocol: HTTPS hosts: - ext-host.example.com tls: mode: SIMPLE serverCertificate: /tmp/tls.crt privateKey: /tmp/tls.key
このゲートウェイ設定により、ポート 443 での ext-host.example.com
からメッシュへの HTTPS トラフィックが可能になりますが、トラフィックのルーティングは指定されません。
ルーティングを指定し、ゲートウェイが意図される通りに機能するには、ゲートウェイを仮想サービスにバインドする必要もあります。これは、以下の例のように、仮想サービスのゲートウェイフィールドを使用して実行します。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: virtual-svc spec: hosts: - ext-host.example.com gateways: - ext-host-gwy
次に、仮想サービスを外部トラフィックのルーティングルールを使用して設定できます。
3.7.2. Ingress ゲートウェイの設定
Ingress ゲートウェイは、受信 HTTP/TCP 接続を受信するメッシュのエッジで稼働するロードバランサーです。このゲートウェイは、公開されるポートおよびプロトコルを設定しますが、これにはトラフィックルーティングの設定は含まれません。Ingress トラフィックに対するトラフィックルーティングは、内部サービス要求の場合と同様に、ルーティングルールで設定されます。
以下の手順では、ゲートウェイを作成し、/productpage
と /login
のパスの外部トラフィックに、Bookinfo サンプルアプリケーションのサービスを公開するように、VirtualService
を設定します。
手順
トラフィックを受け入れるゲートウェイを作成します。
YAML ファイルを作成し、以下の YAML をこれにコピーします。
ゲートウェイの例 (gateway.yaml)
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: info-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"
YAML ファイルを適用します。
$ oc apply -f gateway.yaml
VirtualService
オブジェクトを作成し、ホストヘッダーを再作成します。YAML ファイルを作成し、以下の YAML をこれにコピーします。
仮想サービスの例
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: info spec: hosts: - "*" gateways: - info-gateway http: - match: - uri: exact: /productpage - uri: prefix: /static - uri: exact: /login - uri: exact: /logout - uri: prefix: /api/v1/products route: - destination: host: productpage port: number: 9080
YAML ファイルを適用します。
$ oc apply -f vs.yaml
ゲートウェイと VirtualService が正しく設定されていることを確認してください。
ゲートウェイ URL を設定します。
export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')
ポート番号を設定します。この例では、
istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。export TARGET_PORT=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.port.targetPort}')
明示的に公開されているページをテストします。
curl -s -I "$GATEWAY_URL/productpage"
想定される結果は
200
です。
3.7.3. Ingress トラフィックの管理
Red Hat OpenShift Service Mesh では、Ingress Gateway は、モニタリング、セキュリティー、ルートルールなどの機能をクラスターに入るトラフィックに適用できるようにします。Service Mesh ゲートウェイを使用して Service Mesh 外のサービスを公開します。
3.7.3.1. Ingress IP およびポートの判別
Ingress 設定は、環境が外部ロードバランサーをサポートするかどうかによって異なります。外部ロードバランサーはクラスターの Ingress IP およびポートに設定されます。クラスターの IP およびポートが外部ロードバランサーに設定されているかどうかを判別するには、以下のコマンドを実行します。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。
$ oc get svc istio-ingressgateway -n istio-system
このコマンドは、namespace のそれぞれの項目の NAME
、TYPE
、CLUSTER-IP
、EXTERNAL-IP
、PORT(S)
、および AGE
を返します。
EXTERNAL-IP
値が設定されている場合、環境には Ingress ゲートウェイに使用できる外部ロードバランサーがあります。
EXTERNAL-IP
の値が <none>
または永続的に <pending>
の場合、環境は Ingress ゲートウェイの外部ロードバランサーを提供しません。
3.7.3.1.1. ロードバランサーを使用した Ingress ポートの判別
お使いの環境に外部ロードバランサーがある場合は、以下の手順に従います。
手順
以下のコマンドを実行して Ingress IP およびポートを設定します。このコマンドは、ターミナルに変数を設定します。
$ export INGRESS_HOST=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
以下のコマンドを実行して Ingress ポートを設定します。
$ export INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
以下のコマンドを実行してセキュアな Ingress ポートを設定します。
$ export SECURE_INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].port}')
以下のコマンドを実行して TCP Ingress ポートを設定します。
$ export TCP_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="tcp")].port}')
一部の環境では、ロードバランサーは IP アドレスの代わりにホスト名を使用して公開される場合があります。この場合、Ingress ゲートウェイの EXTERNAL-IP
値は IP アドレスではありません。これはホスト名であり、直前のコマンドは INGRESS_HOST
環境変数の設定に失敗します。
失敗した場合は、以下のコマンドを使用して INGRESS_HOST
値を修正します。
$ export INGRESS_HOST=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
3.7.3.1.2. ロードバランサーのない Ingress ポートの判別
お使いの環境に外部ロードバランサーがない場合は、Ingress ポートを判別し、代わりにノードポートを使用します。
手順
Ingress ポートを設定します。
$ export INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
以下のコマンドを実行してセキュアな Ingress ポートを設定します。
$ export SECURE_INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')
以下のコマンドを実行して TCP Ingress ポートを設定します。
$ export TCP_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="tcp")].nodePort}')
3.7.4. 自動ルート作成
Istio ゲートウェイの OpenShift ルートは、Red Hat OpenShift Service Mesh で自動的に管理されます。Istio ゲートウェイが Service Mesh 内で作成され、更新され、削除されるたびに、OpenShift ルートが作成され、更新され、削除されます。
3.7.4.1. 自動ルート作成の有効化
Istio OpenShift Routing (IOR) と呼ばれる Red Hat OpenShift Service Mesh コントロールプレーンコンポーネントは、ゲートウェイルートを同期させます。コントロールプレーンのデプロイメントの一部として IOR を有効にします。
ゲートウェイに TLS セクションが含まれる場合、OpenShift ルートは TLS をサポートするように設定されます。
-
ServiceMeshControlPlane
リソースで、ior_enabled
パラメーターを追加し、これをtrue
に設定します。たとえば、以下のリソーススニペットを参照してください。
spec: istio: gateways: istio-egressgateway: autoscaleEnabled: false autoscaleMin: 1 autoscaleMax: 5 istio-ingressgateway: autoscaleEnabled: false autoscaleMin: 1 autoscaleMax: 5 ior_enabled: true
3.7.4.2. サブドメイン
Red Hat OpenShift Service Mesh はサブドメインでルートを作成しますが、OpenShift Container Platform はこれを有効にするように設定される必要があります。*.domain.com
などのサブドメインはサポートされますが、デフォルトでは設定されません。ワイルドカードホストゲートウェイを設定する前に OpenShift Container Platform ワイルドカードポリシーを設定します。詳細は「リンク」のセクションを参照してください。
以下のゲートウェイが作成される場合は、次のコマンドを実行します。
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: gateway1 spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - www.info.com - info.example.com
次に、以下の OpenShift ルートが自動的に作成されます。ルートが以下のコマンドを使用して作成されていることを確認できます。
$ oc -n <control_plane_namespace> get routes
予想される出力
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD gateway1-lvlfn info.example.com istio-ingressgateway <all> None gateway1-scqhv www.info.com istio-ingressgateway <all> None
このゲートウェイが削除されると、Red Hat OpenShift Service Mesh はルートを削除します。ただし、手動で作成されたルートは Red Hat OpenShift Service Mesh によって変更されることはありません。
3.7.5. サービスエントリーについて
サービスエントリーは、Red Hat OpenShift Service Mesh が内部で維持するサービスレジストリーにエントリーを追加します。サービスエントリーの追加後、Envoy プロキシーはメッシュ内のサービスであるかのようにトラフィックをサービスに送信できます。サービスエントリーを使用すると、以下が可能になります。
- Service Mesh 外で実行されるサービスのトラフィックを管理します。
- Web から消費される API やレガシーインフラストラクチャーのサービスへのトラフィックなど、外部宛先のトラフィックをリダイレクトし、転送します。
- 外部宛先の再試行、タイムアウト、およびフォールトインジェクションポリシーを定義します。
- 仮想マシンをメッシュに追加して、仮想マシン (VM) でメッシュサービスを実行します。
別のクラスターからメッシュにサービスを追加し、Kubernetes でマルチクラスター Red Hat OpenShift Service Mesh メッシュを設定します。
サービスエントリーの例
以下の mesh-external サービスエントリーの例では、ext-resource
の外部依存関係を Red Hat OpenShift Service Mesh サービスレジストリーに追加します。
apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: svc-entry spec: hosts: - ext-svc.example.com ports: - number: 443 name: https protocol: HTTPS location: MESH_EXTERNAL resolution: DNS
hosts
フィールドを使用して外部リソースを指定します。これを完全に修飾することも、ワイルドカードの接頭辞が付けられたドメイン名を使用することもできます。
仮想サービスおよび宛先ルールを設定して、メッシュ内の他のサービスのトラフィックを設定するのと同じように、サービスエントリーへのトラフィックを制御できます。たとえば、以下の宛先ルールでは、トラフィックルートを、サービスエントリーを使用して設定される ext-svc.example.com
外部サービスへの接続のセキュリティーを保護するために相互 TLS を使用するように設定します。
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: ext-res-dr spec: host: ext-svc.example.com trafficPolicy: tls: mode: MUTUAL clientCertificate: /etc/certs/myclientcert.pem privateKey: /etc/certs/client_private_key.pem caCertificates: /etc/certs/rootcacerts.pem
3.7.6. VirtualServices の使用
仮想サービスを使用して、Red Hat OpenShift Service Mesh で複数バージョンのマイクロサービスに要求を動的にルーティングできます。仮想サービスを使用すると、以下が可能になります。
- 単一の仮想サービスで複数のアプリケーションサービスに対応する。メッシュが Kubernetes を使用する場合などに、仮想サービスを特定の namespace のすべてのサービスを処理するように設定できます。仮想サービスを使用すると、モノリシックなアプリケーションをシームレスに、個別のマイクロサービスで構成されるサービスに変換できます。
- ingress および egress トラフィックを制御できるようにゲートウェイと組み合わせてトラフィックルールを設定する。
3.7.6.1. VirtualServices の設定
要求は、仮想サービスを使用して Service Mesh 内のサービスにルーティングされます。それぞれの仮想サービスは、順番に評価される一連のルーティングルールで構成されます。Red Hat OpenShift Service Mesh は、仮想サービスへのそれぞれの指定された要求をメッシュ内の特定の実際の宛先に一致させます。
仮想サービスがない場合、Red Hat OpenShift Service Mesh はすべてのサービスインスタンス間で最小要求負荷分散を使用してトラフィックを分散します。仮想サービスを使用すると、1 つ以上のホスト名のトラフィック動作を指定できます。仮想サービスのルーティングルールでは、仮想サービスのトラフィックを適切な宛先に送信する方法を Red Hat OpenShift Service Mesh に指示します。ルートの宛先は、同じサービスのバージョンまたは全く異なるサービスにできます。
手順
アプリケーションに接続するユーザーに基づき、異なるバージョンの Bookinfo アプリケーションサービスのサンプルに、要求をルーティングする以下の例を使用して、YAML ファイルを作成します。
VirtualService.yaml の例
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: end-user: exact: jason route: - destination: host: reviews subset: v2 - route: - destination: host: reviews subset: v3
以下のコマンドを実行して
VirtualService.yaml
を適用します。VirtualService.yaml
はファイルへのパスです。$ oc apply -f <VirtualService.yaml>
3.7.6.2. VirtualService 設定リファレンス
パラメーター | 説明 |
---|---|
spec: hosts: |
|
spec: http: - match: |
|
spec: http: - match: - destination: |
route セクションの |
3.7.7. 宛先ルールについて
宛先ルールは仮想サービスのルーティングルールが評価された後に適用されるため、それらはトラフィックの実際の宛先に適用されます。仮想サービスはトラフィックを宛先にルーティングします。宛先ルールでは、その宛先のトラフィックに生じる内容を設定します。
デフォルトでは、Red Hat OpenShift Service Mesh は最小要求負荷分散ポリシーを使用します。その場合は、アクティブな接続の数が最も少ないプール内のサービスインスタンスが要求を受け取ります。Red Hat OpenShift Service Mesh は以下のモデルもサポートします。このモデルは、特定のサービスまたはサービスサブセットへの要求の宛先ルールに指定できます。
- Random: 要求はプール内のインスタンスにランダムに転送されます。
- Weighted: 要求は特定のパーセンテージに応じてプールのインスタンスに転送されます。
- Least requests: 要求は要求の数が最も少ないインスタンスに転送されます。
宛先ルールの例
以下の宛先ルールの例では、異なる負荷分散ポリシーで my-svc
宛先サービスに 3 つの異なるサブセットを設定します。
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: my-destination-rule spec: host: my-svc trafficPolicy: loadBalancer: simple: RANDOM subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 trafficPolicy: loadBalancer: simple: ROUND_ROBIN - name: v3 labels: version: v3
このガイドでは Bookinfo サンプルアプリケーションを参照して、サンプルアプリケーションでのルーティングの例を説明します。Bookinfo アプリケーション をインストールして、これらのルーティングのサンプルがどのように機能するかを確認します。
3.7.8. Bookinfo ルーティングチュートリアル
Service Mesh Bookinfo サンプルアプリケーションは、それぞれが複数のバージョンを持つ 4 つの別個のマイクロサービスで構成されます。Bookinfo サンプルアプリケーションをインストールした後に、reviews
マイクロサービスの 3 つの異なるバージョンが同時に実行されます。
ブラウザーで Bookinfo アプリケーションの /product
ページにアクセスして数回更新すると、書評の出力に星評価が含まれる場合と含まれない場合があります。ルーティング先の明示的なデフォルトサービスバージョンがない場合、Service Mesh は、利用可能なすべてのバージョンに要求をルーティングしていきます。
このチュートリアルは、すべてのトラフィックをマイクロサービスの v1
(バージョン 1) にルーティングするルールを適用するのに役立ちます。後に、HTTP リクエストヘッダーの値に基づいてトラフィックをルーティングするためのルールを適用できます。
前提条件
- 以下の例に合わせて Bookinfo サンプルアプリケーションをデプロイする。
3.7.8.1. 仮想サービスの適用
以下の手順では、マイクロサービスのデフォルトバージョンを設定する仮想サービスを適用して、各マイクロサービスの v1
にすべてのトラフィックをルーティングします。
手順
仮想サービスを適用します。
$ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.6/samples/info/networking/virtual-service-all-v1.yaml
仮想サービスの適用を確認するには、以下のコマンドで定義されたルートを表示します。
$ oc get virtualservices -o yaml
このコマンドでは、YAML 形式で
kind: VirtualService
のリソースを返します。
Service Mesh を Bookinfo マイクロサービスの v1
バージョン (例: reviews
サービスバージョン 1) にルーティングするように設定しています。
3.7.8.2. 新規ルート設定のテスト
Bookinfo アプリケーションの /productpage
を更新して、新しい設定をテストします。
手順
GATEWAY_URL
パラメーターの値を設定します。この変数を使用して、Bookinfo 製品ページの URL を後で見つけることができます。この例では、istio-system はコントロールプレーンプロジェクトの名前です。export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')
以下のコマンドを実行して、製品ページの URL を取得します。
echo "http://$GATEWAY_URL/productpage"
- ブラウザーで Bookinfo サイトを開きます。
更新回数に関係なく、ページのレビュー部分は星評価なしに表示されます。これは、Service Mesh を、reviews サービスのすべてのトラフィックをバージョン reviews:v1
にルーティングするように設定しているためであり、サービスのこのバージョンは星評価サービスにアクセスしません。
Service Mesh は、トラフィックを 1 つのバージョンのサービスにルーティングするようになりました。
3.7.8.3. ユーザーアイデンティティーに基づくルート
ルート設定を変更して、特定のユーザーからのトラフィックすべてが特定のサービスバージョンにルーティングされるようにします。この場合、jason
という名前のユーザーからのトラフィックはすべて、サービス reviews:v2
にルーティングされます。
Service Mesh には、ユーザーアイデンティティーに関する特別な組み込み情報はありません。この例は、productpage
サービスが reviews サービスへのすべてのアウトバウンド HTTP リクエストにカスタム end-user
ヘッダーを追加することで有効になります。
手順
以下のコマンドを実行して、Bookinfo アプリケーション例でユーザーベースのルーティングを有効にします。
$ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.6/samples/info/networking/virtual-service-reviews-test-v2.yaml
以下のコマンドを実行して、ルールの作成を確認します。このコマンドは、
kind: VirtualService
のすべてのリソースを YAML 形式で返します。$ oc get virtualservice reviews -o yaml
-
Bookinfo アプリケーションの
/productpage
で、パスワードなしでユーザーjason
としてログインします。 - ブラウザーを更新します。各レビューの横に星評価が表示されます。
-
別のユーザーとしてログインします (任意の名前を指定します)。ブラウザーを更新します。これで星がなくなりました。Jason 以外のすべてのユーザーのトラフィックが
reviews:v1
にルーティングされるようになりました。
ユーザーアイデンティティーに基づいてトラフィックをルーティングするように Bookinfo のアプリケーションサンプルが正常に設定されています。
3.7.9. 関連情報
OpenShift Container Platform ワイルドカードポリシーの設定に関する詳細は、ワイルドカードルートの使用 を参照してください。