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 リソースを作成して、メッシュのメンバーにする必要があります。

手順

  1. 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
    1
    sidecar.istio.io/inject フィールドを "true" に設定して、ゲートウェイの注入を有効にします。
    2
    Pod が起動するたびにイメージが自動的に更新されるように、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
  3. spec.security.manageNetworkPolicytrue に設定されている場合は常に必要となる、クラスターの外部からの新しいゲートウェイへのアクセスを許可します。

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: gatewayingress
      namespace: istio-ingress
    spec:
      podSelector:
        matchLabels:
          istio: ingressgateway
      ingress:
        - {}
      policyTypes:
      - Ingress
  4. イングレストラフィックが増加すると、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
  5. ノードで実行する必要がある 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 のそれぞれの項目の NAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)、および AGE を返します。

EXTERNAL-IP 値が設定されている場合、環境には Ingress ゲートウェイに使用できる外部ロードバランサーがあります。

EXTERNAL-IP の値が <none> または永続的に <pending> の場合、環境は Ingress ゲートウェイの外部ロードバランサーを提供しません。サービスの ノードポート を使用してゲートウェイにアクセスできます。

1.14.1.3.1.1. ロードバランサーを使用した Ingress ポートの判別

お使いの環境に外部ロードバランサーがある場合は、以下の手順に従います。

手順

  1. 以下のコマンドを実行して Ingress IP およびポートを設定します。このコマンドは、ターミナルに変数を設定します。

    $ export INGRESS_HOST=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
  2. 以下のコマンドを実行して Ingress ポートを設定します。

    $ export INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
  3. 以下のコマンドを実行してセキュアな Ingress ポートを設定します。

    $ export SECURE_INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].port}')
  4. 以下のコマンドを実行して 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 ポートを判別し、代わりにノードポートを使用します。

手順

  1. Ingress ポートを設定します。

    $ export INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
  2. 以下のコマンドを実行してセキュアな Ingress ポートを設定します。

    $ export SECURE_INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')
  3. 以下のコマンドを実行して 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 を設定します。

手順

  1. トラフィックを受け入れるゲートウェイを作成します。

    1. 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:
          - "*"

    2. YAML ファイルを適用します。

      $ oc apply -f gateway.yaml
  2. VirtualService オブジェクトを作成し、ホストヘッダーを再作成します。

    1. 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

    2. YAML ファイルを適用します。

      $ oc apply -f vs.yaml
  3. ゲートウェイと VirtualService が正しく設定されていることを確認してください。

    1. ゲートウェイ URL を設定します。

      export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')
    2. ポート番号を設定します。この例では、istio-system が Service Mesh コントロールプレーンプロジェクトの名前となります。

      export TARGET_PORT=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.port.targetPort}')
    3. 明示的に公開されているページをテストします。

      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.enabledfalse に設定します。たとえば、以下のリソーススニペットを参照してください。

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 に指示します。ルートの宛先は、同じサービスのバージョンまたは全く異なるサービスにできます。

手順

  1. アプリケーションに接続するユーザーに基づき、異なるバージョンの 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

  2. 以下のコマンドを実行して VirtualService.yaml を適用します。VirtualService.yaml はファイルへのパスです。

    $ oc apply -f <VirtualService.yaml>

1.14.4.2. VirtualService 設定リファレンス

パラメーター説明
spec:
  hosts:

hosts フィールドには、ルーティングルールが適用される仮想サービスのユーザーの宛先アドレスが一覧表示されます。これは、サービスへの要求送信に使用するアドレスです。仮想サービスのホスト名は、IP アドレス、DNS 名または完全修飾ドメイン名に解決される短縮名になります。

spec:
  http:
  - match:

http セクションには、ホストフィールドで指定された宛先に送信される HTTP/1.1、HTTP2、および gRPC トラフィックのルーティングの一致条件とアクションを記述する仮想サービスのルーティングルールが含まれます。ルーティングルールは、トラフィックの宛先と、指定の一致条件で設定されます。この例の最初のルーティングルールには条件があり、match フィールドで始まります。この例では、このルーティングはユーザー jason からの要求すべてに適用されます。headersend-user、および exact フィールドを追加し、適切な要求を選択します。

spec:
  http:
  - match:
    - destination:

route セクションの destination フィールドは、この条件に一致するトラフィックの実際の宛先を指定します。仮想サービスのホストとは異なり、宛先のホストは Red Hat OpenShift Service Mesh サービスレジストリーに存在する実際の宛先でなければなりません。これは、プロキシーが含まれるメッシュサービス、またはサービスエントリーを使用して追加されたメッシュ以外のサービスである可能性があります。この例では、ホスト名は Kubernetes サービス名です。

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.manageNetworkPolicyfalse に設定できます。

注記

spec.security.manageNetworkPolicy を無効にすると、Red Hat OpenShift Service Mesh は、NetworkPolicy オブジェクトをひとつも作成しません。システム管理者は、ネットワークを管理し、この原因の問題を修正します。

前提条件

  • Red Hat OpenShift Service Mesh Operator バージョン 2.1.1 以降がインストールされている。
  • ServiceMeshControlPlane リソースはバージョン 2.1 以降に更新されている。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators をクリックします。
  2. Project メニューから、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、ServiceMeshControlPlane の名前 (basic-install など) をクリックします。
  4. Create ServiceMeshControlPlane Details ページで、YAML をクリックして設定を変更します。
  5. 以下の例のように、ServiceMeshControlPlane フィールド spec.security.manageNetworkPolicyfalse に設定します。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
          manageNetworkPolicy: false
  6. Save をクリックします。

1.14.7. トラフィック管理のサイドカーの設定

デフォルトでは、Red Hat OpenShift Service Mesh は、関連するワークロードのすべてのポートでトラフィックを受け入れ、トラフィックの転送時にメッシュ内のすべてのワークロードに到達するように、すべての Envoy プロキシーを設定します。サイドカー設定を使用して以下を実行できます。

  • Envoy プロキシーが受け入れるポートとプロトコルのセットを微調整します。
  • Envoy プロキシーが到達できるサービスのセットを制限します。
注記

サービスメッシュのパフォーマンスを最適化するには、Envoy プロキシー設定の制限を検討してください。

Bookinfo サンプルアプリケーションで、同じ namespace およびコントロールプレーンで実行されている他のサービスに度のサービスからでもアクセスできるように Sidecar を設定します。この Sidecar 設定は、Red Hat OpenShift Service Mesh ポリシーおよび Telemetry 機能での使用に必要になります。

手順

  1. 以下の例を使用して YAML ファイルを作成し、サイドカー設定を特定の namespace の全ワークロードに適用するように指定します。それ以外の場合は、workloadSelector を使用して特定のワークロードを選択します。

    sidecar.yaml の例

    apiVersion: networking.istio.io/v1alpha3
    kind: Sidecar
    metadata:
      name: default
      namespace: info
    spec:
      egress:
      - hosts:
        - "./*"
        - "istio-system/*"

  2. 以下のコマンドを実行して sidecar.yaml を適用します。ここでは、sidecar.yaml はファイルへのパスです。

    $ oc apply -f sidecar.yaml
  3. サイドカーが正常に作成されたことを確認するには、以下のコマンドを実行します。

    $ 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 にすべてのトラフィックをルーティングします。

手順

  1. 仮想サービスを適用します。

    $ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/info/networking/virtual-service-all-v1.yaml
  2. 仮想サービスの適用を確認するには、以下のコマンドで定義されたルートを表示します。

    $ oc get virtualservices -o yaml

    このコマンドでは、YAML 形式で kind: VirtualService のリソースを返します。

Service Mesh を Bookinfo マイクロサービスの v1 バージョン (例: reviews サービスバージョン 1) にルーティングするように設定しています。

1.14.8.3. 新規ルート設定のテスト

Bookinfo アプリケーションの /productpage を更新して、新しい設定をテストします。

手順

  1. GATEWAY_URL パラメーターの値を設定します。この変数を使用して、Bookinfo 製品ページの URL を後で見つけることができます。この例では、istio-system はコントロールプレーンプロジェクトの名前です。

    export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')
  2. 以下のコマンドを実行して、製品ページの URL を取得します。

    echo "http://$GATEWAY_URL/productpage"
  3. ブラウザーで Bookinfo サイトを開きます。

更新回数に関係なく、ページのレビュー部分は星評価なしに表示されます。これは、Service Mesh を、reviews サービスのすべてのトラフィックをバージョン reviews:v1 にルーティングするように設定しているためであり、サービスのこのバージョンは星評価サービスにアクセスしません。

サービスメッシュは、トラフィックを 1 つのバージョンのサービスにルーティングするようになりました。

1.14.8.4. ユーザーアイデンティティーに基づくルート

ルート設定を変更して、特定のユーザーからのトラフィックすべてが特定のサービスバージョンにルーティングされるようにします。この場合、jason という名前のユーザーからのトラフィックはすべて、サービス reviews:v2 にルーティングされます。

Service Mesh には、ユーザーアイデンティティーに関する特別な組み込み情報はありません。この例は、productpage サービスが reviews サービスへのすべてのアウトバウンド HTTP リクエストにカスタム end-user ヘッダーを追加することで有効になります。

手順

  1. 以下のコマンドを実行して、Bookinfo アプリケーション例でユーザーベースのルーティングを有効にします。

    $ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/info/networking/virtual-service-reviews-test-v2.yaml
  2. 以下のコマンドを実行して、ルールの作成を確認します。このコマンドは、kind: VirtualService のすべてのリソースを YAML 形式で返します。

    $ oc get virtualservice reviews -o yaml
  3. Bookinfo アプリケーションの /productpage で、パスワードなしでユーザー jason としてログインします。
  4. ブラウザーを更新します。各レビューの横に星評価が表示されます。
  5. 別のユーザーとしてログインします (任意の名前を指定します)。ブラウザーを更新します。これで星がなくなりました。Jason 以外のすべてのユーザーのトラフィックが reviews:v1 にルーティングされるようになりました。

ユーザーアイデンティティーに基づいてトラフィックをルーティングするように Bookinfo のアプリケーションサンプルが正常に設定されています。