2.7. トラフィック管理

警告

こちらは、サポートされなくなった Red Hat OpenShift Service Mesh リリースのドキュメントです。

Service Mesh バージョン 1.0 および 1.1 コントロールプレーンはサポートされなくなりました。Service Mesh コントロールプレーンのアップグレードは、Service Mesh の アップグレード を参照してください。

特定の Red Hat Service Mesh リリースのサポートステータスは、製品ライフサイクルページ を参照してください。

Red Hat OpenShift Service Mesh のサービス間のトラフィックのフローおよび API 呼び出しを制御できます。たとえば、サービスメッシュの一部のサービスはメッシュ内で通信する必要があり、他のサービスは非表示にする必要がある場合があります。トラフィックを管理して、特定のバックエンドサービスを非表示にし、サービスを公開し、テストまたはバージョン管理デプロイメントを作成し、または一連のサービスのセキュリティーの層を追加します。

2.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 仮想サービスをゲートウェイにバインドし、サービスメッシュ内の他のデータプレーントラフィックのようにゲートウェイトラフィックを管理できます。

ゲートウェイは 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

次に、仮想サービスを外部トラフィックのルーティングルールを使用して設定できます。

2.7.2. 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 です。

2.7.3. Ingress トラフィックの管理

Red Hat OpenShift Service Mesh では、Ingress Gateway は、モニタリング、セキュリティー、ルートルールなどの機能をクラスターに入るトラフィックに適用できるようにします。Service Meshゲートウェイを使用してサービスメッシュ外のサービスを公開します。

2.7.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 ゲートウェイの外部ロードバランサーを提供しません。サービスの ノードポート を使用してゲートウェイにアクセスできます。

2.7.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}')
2.7.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}')

2.7.4. 自動ルート作成

Istio ゲートウェイの OpenShift ルートは、Red Hat OpenShift Service Mesh で自動的に管理されます。Istio ゲートウェイがサービスメッシュ内で作成され、更新され、削除されるたびに、OpenShift ルートが作成され、更新され、削除されます。

2.7.4.1. 自動ルート作成の有効化

Istio OpenShift Routing (IOR) と呼ばれる Red Hat OpenShift Service Mesh コントロールプレーンコンポーネントは、ゲートウェイルートを同期させます。コントロールプレーンのデプロイメントの一部として IOR を有効にします。

ゲートウェイに TLS セクションが含まれる場合、OpenShift ルートは TLS をサポートするように設定されます。

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

2.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 によって変更されることはありません。

2.7.5. サービスエントリーについて

サービスエントリーは、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

2.7.6. VirtualServices の使用

仮想サービスを使用して、Red Hat OpenShift Service Mesh で複数バージョンのマイクロサービスに要求を動的にルーティングできます。仮想サービスを使用すると、以下が可能になります。

  • 単一の仮想サービスで複数のアプリケーションサービスに対応する。メッシュが Kubernetes を使用する場合などに、仮想サービスを特定の namespace のすべてのサービスを処理するように設定できます。仮想サービスを使用すると、モノリシックなアプリケーションをシームレスに、個別のマイクロサービスで設定されるサービスに変換できます。
  • ingress および egress トラフィックを制御できるようにゲートウェイと組み合わせてトラフィックルールを設定する。

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

2.7.6.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 サービス名です。

2.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 アプリケーション をインストールして、これらのルーティングのサンプルがどのように機能するかを確認します。

2.7.8. Bookinfo ルーティングチュートリアル

Service Mesh Bookinfo サンプルアプリケーションは、それぞれが複数のバージョンを持つ 4 つの別個のマイクロサービスで設定されます。Bookinfo サンプルアプリケーションをインストールした後に、reviews マイクロサービスの 3 つの異なるバージョンが同時に実行されます。

ブラウザーで Bookinfo アプリケーションの /product ページにアクセスして数回更新すると、書評の出力に星評価が含まれる場合と含まれない場合があります。ルーティング先の明示的なデフォルトサービスバージョンがない場合、Service Mesh は、利用可能なすべてのバージョンに要求をルーティングしていきます。

このチュートリアルは、すべてのトラフィックをマイクロサービスの v1 (バージョン 1) にルーティングするルールを適用するのに役立ちます。後に、HTTP リクエストヘッダーの値に基づいてトラフィックをルーティングするためのルールを適用できます。

前提条件:

  • 以下の例に合わせて Bookinfo サンプルアプリケーションをデプロイする。

2.7.8.1. 仮想サービスの適用

以下の手順では、マイクロサービスのデフォルトバージョンを設定する仮想サービスを適用して、各マイクロサービスの 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) にルーティングするように設定しています。

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

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 つのバージョンのサービスにルーティングするようになりました。

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

ルート設定を変更して、特定のユーザーからのトラフィックすべてが特定のサービスバージョンにルーティングされるようにします。この場合、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 のアプリケーションサンプルが正常に設定されています。

2.7.9. 関連情報

OpenShift Container Platform ワイルドカードポリシーの設定に関する詳細は、ワイルドカードルートの使用 を参照してください。