1.14. Service Mesh でのトラフィックの管理
Red Hat OpenShift Service Mesh のサービス間におけるトラフィックのフローおよび API 呼び出しを制御できます。サービスメッシュ内の一部のサービスはメッシュ内で通信する必要がある場合があり、他のサービスは非表示にする必要がある場合があります。トラフィックを管理して、特定のバックエンドサービスを非表示にし、サービスを公開し、テストまたはバージョン管理デプロイメントを作成し、または一連のサービスのセキュリティーの層を追加できます。
1.14.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 仮想サービスをゲートウェイにバインドし、サービスメッシュ内の他のデータプレーントラフィックのようにゲートウェイトラフィックを管理することができます。
ゲートウェイは ingress トラフィックの管理に主に使用されますが、egress ゲートウェイを設定することもできます。egress ゲートウェイを使用すると、メッシュからのトラフィック専用の終了ノードを設定できます。これにより、サービスメッシュにセキュリティー制御を追加することで、外部ネットワークにアクセスできるサービスを制限できます。また、ゲートウェイを使用して完全に内部のプロキシーを設定することもできます。
ゲートウェイの例
ゲートウェイリソースは、着信または発信 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
次に、仮想サービスを外部トラフィックのルーティングルールを使用して設定できます。
1.14.1.1. ゲートウェイ挿入の有効化
ゲートウェイ設定は、サービスワークロードと並行して実行されるサイドカー Envoy プロキシーではなく、メッシュのエッジで実行されるスタンドアロン Envoy プロキシーに適用されます。ゲートウェイは Envoy プロキシーであるため、サイドカーを挿入する方法と同様に、ゲートウェイを自動的に挿入するように Service Mesh を設定できます。
ゲートウェイの自動挿入を使用すると、ServiceMeshControlPlane
リソースから独立してゲートウェイをデプロイおよび管理し、ユーザーアプリケーションでゲートウェイを管理できます。ゲートウェイのデプロイメントに自動挿入を使用すると、開発者は操作を簡略化しながら、ゲートウェイのデプロイメントを完全に制御できます。新しいアップグレードが利用可能になった場合、または設定が変更された場合は、ゲートウェイ Pod を再起動して更新します。そうすることで、ゲートウェイデプロイメントの操作エクスペリエンスが、サイドカーの操作と同じになります。
ServiceMeshControlPlane
namespace (たとえば、istio-system
namespace) では、操作はデフォルトで無効になっています。セキュリティーのベストプラクティスとして、コントロールプレーンとは異なる namespace にゲートウェイをデプロイします。
1.14.1.2. 自動ゲートウェイイ挿入のデプロイ
ゲートウェイをデプロイする場合、挿入ラベルまたはアノテーションをゲートウェイ deployment
オブジェクトに追加して、挿入をオプトインする必要があります。次の例では、ゲートウェイをデプロイします。
前提条件
-
namespace は、
ServiceMeshMemberRoll
で定義するか、ServiceMeshMember
リソースを作成して、メッシュのメンバーにする必要があります。
手順
Istio Ingress ゲートウェイに一意のラベルを設定します。この設定は、ゲートウェイがワークロードを選択できるようにするために必要です。この例では、ゲートウェイの名前として
ingressgateway
を使用しています。apiVersion: v1 kind: Service metadata: name: istio-ingressgateway namespace: istio-ingress spec: type: ClusterIP selector: istio: ingressgateway ports: - name: http port: 80 targetPort: 8080 - name: https port: 443 targetPort: 8443 --- apiVersion: apps/v1 kind: Deployment metadata: name: istio-ingressgateway namespace: istio-ingress spec: selector: matchLabels: istio: ingressgateway template: metadata: annotations: inject.istio.io/templates: gateway labels: istio: ingressgateway sidecar.istio.io/inject: "true" 1 spec: containers: - name: istio-proxy image: auto 2
TLS の認証情報の読み取りを許可するロールを設定します。
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: istio-ingressgateway-sds namespace: istio-ingress rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: istio-ingressgateway-sds namespace: istio-ingress roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: istio-ingressgateway-sds subjects: - kind: ServiceAccount name: default
spec.security.manageNetworkPolicy
がtrue
に設定されている場合は常に必要となる、クラスターの外部からの新しいゲートウェイへのアクセスを許可します。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: gatewayingress namespace: istio-ingress spec: podSelector: matchLabels: istio: ingressgateway ingress: - {} policyTypes: - Ingress
イングレストラフィックが増加すると、Pod を自動的にスケーリングします。この例では、最小レプリカ数を
2
に、最大レプリカ数を5
に設定します。また、使用率が 80% に達すると、別のレプリカが作成されます。apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: labels: istio: ingressgateway release: istio name: ingressgatewayhpa namespace: istio-ingress spec: maxReplicas: 5 metrics: - resource: name: cpu target: averageUtilization: 80 type: Utilization type: Resource minReplicas: 2 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: istio-ingressgateway
ノードで実行する必要がある Pod の最小数を指定します。この例では、Pod が新しいノードで再起動した場合に、1 つのレプリカが実行していることを確認します。
apiVersion: policy/v1 kind: PodDisruptionBudget metadata: labels: istio: ingressgateway release: istio name: ingressgatewaypdb namespace: istio-ingress spec: minAvailable: 1 selector: matchLabels: istio: ingressgateway
1.14.1.3. Ingress トラフィックの管理
Red Hat OpenShift Service Mesh では、Ingress Gateway は、モニタリング、セキュリティー、ルートルールなどの機能をクラスターに入るトラフィックに適用できるようにします。Service Meshゲートウェイを使用してサービスメッシュ外のサービスを公開します。
1.14.1.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 ゲートウェイの外部ロードバランサーを提供しません。サービスの ノードポート を使用してゲートウェイにアクセスできます。
1.14.1.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}')
1.14.1.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}')
1.14.1.4. 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
です。
1.14.2. 自動ルートについて
ゲートウェイの OpenShift ルートは Service Mesh で自動的に管理されます。Istio ゲートウェイがサービスメッシュ内で作成され、更新され、削除されるたびに、OpenShift ルートが作成され、更新され、削除されます。
1.14.2.1. サブドメインのあるルート
Red Hat OpenShift Service Mesh はサブドメインでルートを作成しますが、OpenShift Container Platform はこれを有効にするように設定される必要があります。*.domain.com
などのサブドメインはサポートされますが、デフォルトでは設定されません。ワイルドカードホストゲートウェイを設定する前に OpenShift Container Platform ワイルドカードポリシーを設定します。
詳細は、ワイルドカードルートの使用 を参照してください。
1.14.2.2. サブドメインルートの作成
以下の例では、サブドメインルートを作成する Bookinfo サンプルアプリケーションにゲートウェイを作成します。
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
Gateway
リソースは、次の OpenShift ルートを作成します。ルートが以下のコマンドを使用して作成されていることを確認できます。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前です。
$ oc -n istio-system 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 によって変更されることはありません。
1.14.2.3. ルートラベルとアノテーション
OpenShift ルートでは、特定のラベルまたはアノテーションが必要になる場合があります。たとえば、OpenShift ルートの高度な機能の一部は、特別なアノテーションを使用して管理されます。以下の関連情報セクションのルート固有のアノテーションを参照してください。
このユースケースおよび他のユースケースでは、Red Hat OpenShift Service Mesh は (kubectl.kubernetes.io
で始まるものを除く) Istio Gateway リソースにあるすべてのラベルとアノテーションを管理対象の OpenShift Route リソースにコピーします。
Service Mesh によって作成される OpenShift ルートで特定のラベルまたはアノテーションが必要な場合は、それらを Istio Gateway リソースで作成すると、Service Mesh で管理される OpenShift ルートリソースにコピーされます。
関連情報
1.14.2.4. 自動ルート作成の無効化
デフォルトで、ServiceMeshControlPlane
リソースは Istio ゲートウェイリソースと OpenShift ルートを自動的に同期します。自動ルート作成を無効にすると、特殊なケースがある場合やルートを手動で制御する場合に、ルートをより柔軟に制御できます。
1.14.2.4.1. 特定のケースでの自動ルート作成の無効化
特定の Istio ゲートウェイの OpenShift ルートの自動管理を無効にする場合は、アノテーション maistra.io/manageRoute: false
をゲートウェイのメタデータ定義に追加する必要があります。Red Hat OpenShift Service Mesh は、他の Istio ゲートウェイの自動管理を維持しつつ、このアノテーションの付いた Istio ゲートウェイを無視します。
1.14.2.4.2. すべてのケースでの自動ルート作成の無効化
メッシュ内のすべてのゲートウェイの OpenShift ルートの自動管理を無効にできます。
Istio ゲートウェイと OpenShift ルート間の統合を無効にするには、ServiceMeshControlPlane
フィールド gateways.openshiftRoute.enabled
を false
に設定します。たとえば、以下のリソーススニペットを参照してください。
apiVersion: maistra.io/v1alpha1 kind: ServiceMeshControlPlane metadata: namespace: istio-system spec: gateways: openshiftRoute: enabled: false
1.14.3. サービスエントリーについて
サービスエントリーは、Red Hat OpenShift Service Mesh が内部で維持するサービスレジストリーにエントリーを追加します。サービスエントリーの追加後、Envoy プロキシーはメッシュ内のサービスであるかのようにトラフィックをサービスに送信できます。サービスエントリーを使用すると、以下が可能になります。
- サービスメッシュ外で実行されるサービスのトラフィックを管理します。
- 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
1.14.4. VirtualServices の使用
仮想サービスを使用して、Red Hat OpenShift Service Mesh で複数バージョンのマイクロサービスに要求を動的にルーティングできます。仮想サービスを使用すると、以下が可能になります。
- 単一の仮想サービスで複数のアプリケーションサービスに対応する。メッシュが Kubernetes を使用する場合などに、仮想サービスを特定の namespace のすべてのサービスを処理するように設定できます。仮想サービスを使用すると、モノリシックなアプリケーションをシームレスに、個別のマイクロサービスで設定されるサービスに変換できます。
- ingress および egress トラフィックを制御できるようにゲートウェイと組み合わせてトラフィックルールを設定する。
1.14.4.1. VirtualServices の設定
要求は、仮想サービスを使用してサービスメッシュ内のサービスにルーティングされます。それぞれの仮想サービスは、順番に評価される一連のルーティングルールで設定されます。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>
1.14.4.2. VirtualService 設定リファレンス
パラメーター | 説明 |
---|---|
spec: hosts: |
|
spec: http: - match: |
|
spec: http: - match: - destination: |
route セクションの |
1.14.5. 宛先ルールについて
宛先ルールは仮想サービスのルーティングルールが評価された後に適用されるため、それらはトラフィックの実際の宛先に適用されます。仮想サービスはトラフィックを宛先にルーティングします。宛先ルールでは、その宛先のトラフィックに生じる内容を設定します。
デフォルトでは、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
1.14.6. ネットワークポリシーについて
Red Hat OpenShift Service Mesh は、Service Mesh コントロールプレーンおよびアプリケーションネームスペースで多数の NetworkPolicies
リソースを自動的に作成し、管理します。これは、アプリケーションとコントロールプレーンが相互に通信できるようにするために使用されます。
たとえば、OpenShift Container Platform クラスターが SDN プラグインを使用するように設定されている場合、Red Hat OpenShift Service Mesh は各メンバープロジェクトで NetworkPolicy
リソースを作成します。これにより、他のメッシュメンバーおよびコントロールプレーンからのメッシュ内のすべての Pod に対する ingress が有効になります。また、これにより Ingress がメンバープロジェクトのみに制限されます。メンバー以外のプロジェクトの Ingress が必要な場合は、NetworkPolicy
を作成してそのトラフィックを許可する必要があります。Service Mesh から namespace を削除する場合、この NetworkPolicy
リソースはプロジェクトから削除されます。
1.14.6.1. NetworkPolicy 自動作成の無効化
NetworkPolicy
リソースの自動作成および管理を無効にする場合 (例: 会社のセキュリティーポリシーを適用したり、メッシュ内の Pod への直接アクセスを許可する場合など) はこれを実行できます。ServiceMeshControlPlane
を編集し、spec.security.manageNetworkPolicy
を false
に設定できます。
spec.security.manageNetworkPolicy
を無効にすると、Red Hat OpenShift Service Mesh は、NetworkPolicy
オブジェクトをひとつも作成しません。システム管理者は、ネットワークを管理し、この原因の問題を修正します。
前提条件
- Red Hat OpenShift Service Mesh Operator バージョン 2.1.1 以降がインストールされている。
-
ServiceMeshControlPlane
リソースはバージョン 2.1 以降に更新されている。
手順
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators をクリックします。 -
Project メニューから、Service Mesh コントロールプレーンをインストールしたプロジェクト (例:
istio-system
) を選択します。 -
Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、
ServiceMeshControlPlane
の名前 (basic-install
など) をクリックします。 -
Create ServiceMeshControlPlane Details ページで、
YAML
をクリックして設定を変更します。 以下の例のように、
ServiceMeshControlPlane
フィールドspec.security.manageNetworkPolicy
をfalse
に設定します。apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane spec: security: manageNetworkPolicy: false
- Save をクリックします。
1.14.7. トラフィック管理のサイドカーの設定
デフォルトで、Red Hat OpenShift Service Mesh は、すべての Envoy プロキシーを、トラフィックの転送時にすべてのポートで関連付けられたワークロードについてのトラフィックを受け入れ、メッシュ内のすべてのワークロードに到達するように設定します。サイドカー設定を使用して以下を実行できます。
- Envoy プロキシーが受け入れるポートとプロトコルのセットを微調整します。
- Envoy プロキシーが到達できるサービスのセットを制限します。
サービスメッシュのパフォーマンスを最適化するには、Envoy プロキシー設定の制限を検討してください。
Bookinfo サンプルアプリケーションで、同じ namespace およびコントロールプレーンで実行されている他のサービスに度のサービスからでもアクセスできるように Sidecar を設定します。この Sidecar 設定は、Red Hat OpenShift Service Mesh ポリシーおよび Telemetry 機能での使用に必要になります。
手順
以下の例を使用して YAML ファイルを作成し、サイドカー設定を特定の namespace の全ワークロードに適用するように指定します。それ以外の場合は、
workloadSelector
を使用して特定のワークロードを選択します。sidecar.yaml の例
apiVersion: networking.istio.io/v1alpha3 kind: Sidecar metadata: name: default namespace: info spec: egress: - hosts: - "./*" - "istio-system/*"
以下のコマンドを実行して
sidecar.yaml
を適用します。ここでは、sidecar.yaml
はファイルへのパスです。$ oc apply -f sidecar.yaml
サイドカーが正常に作成されたことを確認するには、以下のコマンドを実行します。
$ oc get sidecar
1.14.8. ルーティングチュートリアル
本書では Bookinfo サンプルアプリケーションを参照して、サンプルアプリケーションでのルーティングの例を説明します。Bookinfo アプリケーション をインストールして、これらのルーティングのサンプルがどのように機能するかを確認します。
1.14.8.1. Bookinfo ルーティングチュートリアル
Service Mesh Bookinfo サンプルアプリケーションは、それぞれが複数のバージョンを持つ 4 つの別個のマイクロサービスで設定されます。Bookinfo サンプルアプリケーションをインストールした後に、reviews
マイクロサービスの 3 つの異なるバージョンが同時に実行されます。
ブラウザーで Bookinfo アプリケーションの /product
ページにアクセスして数回更新すると、書評の出力に星評価が含まれる場合と含まれない場合があります。ルーティング先の明示的なデフォルトサービスバージョンがない場合、Service Mesh は、利用可能なすべてのバージョンに要求をルーティングしていきます。
このチュートリアルは、すべてのトラフィックをマイクロサービスの v1
(バージョン 1) にルーティングするルールを適用するのに役立ちます。後に、HTTP リクエストヘッダーの値に基づいてトラフィックをルーティングするためのルールを適用できます。
前提条件:
- 以下の例に合わせて Bookinfo サンプルアプリケーションをデプロイする。
1.14.8.2. 仮想サービスの適用
以下の手順では、マイクロサービスのデフォルトバージョンを設定する仮想サービスを適用して、各マイクロサービスの v1
にすべてのトラフィックをルーティングします。
手順
仮想サービスを適用します。
$ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.3/samples/info/networking/virtual-service-all-v1.yaml
仮想サービスの適用を確認するには、以下のコマンドで定義されたルートを表示します。
$ oc get virtualservices -o yaml
このコマンドでは、YAML 形式で
kind: VirtualService
のリソースを返します。
Service Mesh を Bookinfo マイクロサービスの v1
バージョン (例: reviews
サービスバージョン 1) にルーティングするように設定しています。
1.14.8.3. 新規ルート設定のテスト
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
にルーティングするように設定しているためであり、サービスのこのバージョンは星評価サービスにアクセスしません。
サービスメッシュは、トラフィックを 1 つのバージョンのサービスにルーティングするようになりました。
1.14.8.4. ユーザーアイデンティティーに基づくルート
ルート設定を変更して、特定のユーザーからのトラフィックすべてが特定のサービスバージョンにルーティングされるようにします。この場合、jason
という名前のユーザーからのトラフィックはすべて、サービス reviews:v2
にルーティングされます。
Service Mesh には、ユーザーアイデンティティーについての特別な組み込み情報はありません。この例は、productpage
サービスが reviews サービスへのすべてのアウトバウンド HTTP リクエストにカスタム end-user
ヘッダーを追加することで有効にされます。
手順
以下のコマンドを実行して、Bookinfo アプリケーション例でユーザーベースのルーティングを有効にします。
$ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.3/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 のアプリケーションサンプルが正常に設定されています。