Red Hat OpenShift 4 での経路を使用したアプリの公開

単一ゾーンのクラシック・クラスターのトラフィック・フロー

次の図は、ルーターがインターネットからのネットワーク・トラフィックを単一ゾーンのクラシック・クラスターのアプリに転送する方法を示しています。

1. アプリに対する要求では、アプリにセットアップした経路のホスト名を使用します。

2. DNS サービスが、サブドメインをルーター・サービスのポータブル・パブリック IP アドレスに解決します。

3. ルーターは要求を受け取り、それをプライベート・ネットワークを介してアプリ・ポッドのプライベート IP アドレスに転送します。 要求パッケージのソース IP アドレスが、ルーター・ポッドが実行されるワーカー・ノードのパブリック IP アドレスに変更されます。 複数のアプリ・インスタンスがクラスターにデプロイされている場合、ルーターは、それらのアプリ・ポッド間に要求を送信します。

4. アプリが応答パケットを返す際には、クライアント要求を転送したルーターが存在するワーカー・ノードの IP アドレスが使用されます。 そして、ルーターがロード・バランサー・サービスを介してクライアントに応答パケットを送信します。

マルチゾーンのクラシック・クラスターのトラフィック・フロー

次の図は、ルーターがインターネットからのネットワーク・トラフィックをマルチゾーンのクラシック・クラスターのアプリに転送する方法を示しています。

1. アプリに対する要求では、アプリにセットアップした経路のホスト名を使用します。

2. DNS サービスが、その経路のサブドメインを、マルチゾーン・ロード・バランサー (MZLB) から正常と報告されたルーター・サービスのポータブル・パブリック IP アドレスに解決します。 MZLB は、クラスターの各ゾーンで、ルーターを公開するサービスのポータブル・パブリック IP アドレスを継続的に検査します。 ラウンドロビン・サイクルでさまざまなゾーンのルーター・サービスが要求を処理します。

3. 解決されたルーター・サービスの IP アドレスに基づいて、ルーターが要求を受信します。

4. ルーターがプライベート・ネットワーク経由でアプリ・ポッドのプライベート IP アドレスに要求を転送します。 要求パッケージのソース IP アドレスが、ルーター・ポッドが実行されるワーカー・ノードのパブリック IP アドレスに変更されます。 各ルーターは、同じゾーンに属するアプリ・インスタンスへの要求と、他のゾーンのアプリ・インスタンスへの要求を送信します。 さらに、1 つのゾーンに複数のアプリ・インスタンスがデプロイされている場合は、ルーターがアプリ・ポッド間で要求を転送します。

5. アプリが応答パケットを返す際には、クライアント要求を転送したルーターが存在するワーカー・ノードの IP アドレスが使用されます。 そして、ルーターがロード・バランサー・サービスを介してクライアントに応答パケットを送信します。

パブリック・クラウド・サービス・エンドポイントがあるマルチゾーン VPC クラスターのトラフィック・フロー

パブリック・クラウド・サービス・エンドポイントを有効にしてマルチゾーン VPC クラスターを作成すると、デフォルトでは、パブリック Ingress コントローラーが作成されます。 Ingress コントローラーは、パブリックでアクセス可能な経路をアプリに割り当て、パブリック・ホスト・ネットワーク・インターフェースでアプリへの要求を listen します。

以下の図は、Ingress コントローラーがインターネットから複数ゾーンの VPC クラスター内のアプリにネットワーク・トラフィックを転送する方法を示しています。

1. アプリに対する要求では、アプリにセットアップした経路のホスト名を使用します。

2. DNS サービスは、経路サブドメインを、Ingress コントローラーに割り当てられた VPC ロード・バランサーのホスト名に解決します。 VPC クラスターでは、Ingress コントローラー・サービスの外部 IP アドレスは浮動アドレスであり、VPC 割り当てのホスト名の背後に保持されます。

3. VPC ロード・バランサーは、VPC ホスト名を、正常と報告された Ingress コントローラー・サービスの使用可能な外部 IP アドレスに解決します。 VPC ロード・バランサーは、クラスター内の各ゾーンで Ingress コントローラーを公開するサービスの外部 IP アドレスを継続的に検査します。

4. 解決された IP アドレスに基づいて、VPC ロード・バランサーは要求を Ingress コントローラー・サービスに送信します。

5. Ingress コントローラーは、プライベート・ネットワークを介してアプリ・ポッドのプライベート IP アドレスに要求を転送します。 要求パケットのソース IP アドレスは、Ingress コントローラー・ポッドが実行されるワーカー・ノードの IP アドレスに変更されます。 各 Ingress コントローラーは、独自のゾーン内のアプリ・インスタンスと、他のゾーン内のアプリ・インスタンスに要求を送信します。 さらに、複数のアプリ・インスタンスが 1 つのゾーンにデプロイされている場合、Ingress コントローラーはアプリ・ポッド間で要求を交換します。

6. アプリは、応答パケットを返すときに、クライアント要求を転送した Ingress コントローラーが存在するワーカー・ノードの IP アドレスを使用します。 その後、Ingress コントローラーは、VPC ロード・バランサーを介して応答パケットをクライアントに送信します。

プライベート・クラウド・サービス・エンドポイントしかないマルチゾーン VPC クラスターのトラフィック・フロー

プライベート・クラウド・サービス・エンドポイントのみを使用して複数ゾーン VPC クラスターを作成すると、デフォルトでは、プライベート Ingress コントローラーが作成されます。 Ingress コントローラーは、プライベートでアクセス可能な経路をアプリに割り当て、プライベート・ホスト・ネットワーク・インターフェースで listen します。 プライベート経路で公開されたアプリには、プライベート VPC ネットワークに接続しているクライアントしかアクセスできません。

以下の図は、Ingress コントローラーがプライベート・ネットワークから複数ゾーンの VPC クラスター内のアプリにネットワーク・トラフィックを転送する方法を示しています。

{: caption="を使用して、プライベート、マルチゾーン、VPCクラスタにアプリを公開Ingress" caption-side="bottom"}を使用して、プライベート、マルチゾーン、VPCクラスタにアプリを公開Ingressコントローラを使用して、プライベート、マルチゾーン、VPCクラスタにアプリを公開

1. プライベートの VPC ネットワークに接続したクライアントが、アプリのプライベート経路を使用してアプリに要求を送信します。 例えば、仮想プライベート・クラウド VPN、IBM Cloud Transit Gateway、IBM Cloud Direct Link などを使用して、オンプレミスのネットワーク、別の VPC、または IBM Cloud クラシック・インフラストラクチャーから、クラスターで実行されているアプリに要求を送信することができます。

2. DNS サービスは、経路サブドメインを、Ingress コントローラーに割り当てられた VPC ロード・バランサーのホスト名に解決します。 VPC クラスターでは、Ingress コントローラー・サービスの IP アドレスは浮動アドレスであり、VPC 割り当てのホスト名の後に保持されます。 経路のサブドメインの DNS レコードはパブリック DNS システムに登録されていますが、DNS 解決サーバーに到達できるのは VPC からであることに注意してください。

3. プライベート VPC ロード・バランサーは、VPC ホスト名を、正常と報告された Ingress コントローラーのゾーン内の使用可能なプライベート IP アドレスに解決します。 VPC ロード・バランサーは、クラスター内の各ゾーンで Ingress コントローラーを公開するサービスの IP アドレスを継続的に検査します。

4. 解決された IP アドレスに基づいて、VPC ロード・バランサーは要求を Ingress コントローラー・サービスに送信します。

5. Ingress コントローラーは、プライベート・ネットワークを介してアプリ・ポッドのプライベート IP アドレスに要求を転送します。 要求パケットのソース IP アドレスは、Ingress コントローラー・ポッドが実行されるワーカー・ノードの IP アドレスに変更されます。 各 Ingress コントローラーは、独自のゾーン内のアプリ・インスタンスと、他のゾーン内のアプリ・インスタンスに要求を送信します。 さらに、複数のアプリ・インスタンスが 1 つのゾーンにデプロイされている場合、Ingress コントローラーはアプリ・ポッド間で要求を交換します。

6. アプリは、応答パケットを返すときに、クライアント要求を転送した Ingress コントローラーが存在するワーカー・ノードの IP アドレスを使用します。 その後、Ingress コントローラーは、VPC ロード・バランサーを介して、IBM Cloud VPC VPN、Transit Gateway、または Direct Link を介してクライアントに応答パケットを送信します。

パブリック・クラウド・サービス・エンドポイントがあるクラシック・クラスターまたは VPC クラスターでパブリック経路をセットアップする

クラスターがクラシック・インフラストラクチャー上で作成されている場合、またはVPCインフラストラクチャ上で作成され、かつクラスター作成時にパブリッククラウドサービスエンドポイントを有効にした場合、そのクラスターにはデフォルトでパブリックIngressコントローラーが設定されます。 この Ingress コントローラーを使用して、アプリのパブリック経路を作成できます。

1. アプリのデプロイメント用の Kubernetes ClusterIP サービスを作成します。 サービスは、Ingress コントローラーがトラフィックを送信できるアプリの内部 IP アドレスを提供します。

   oc expose deploy <app_deployment_name> --name my-app-svc
   

2. アプリのドメインを選択します。 ルートURLは130文字以内である必要がある点に注意してください 。 IBM-provided domain: カスタムドメインを使用する必要がない場合、 <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud という形式のルートホスト名が自動的に生成されます。 カスタム・ドメイン: カスタム・ドメインを指定する場合は、お客様の DNS プロバイダーまたは IBM Cloud® Internet Services を使用します。

   1. 外部 IP 列の各ゾーンのパブリック Ingress コントローラー・サービスのパブリック IP アドレスを取得します。 ワーカー・ノードがある最初のゾーンの Ingress コントローラー・サービスの名前は常に router-default になり、その後クラスターに追加するゾーンの Ingress コントローラー・サービスの名前は router-dal12 になることに注意してください。

       oc get svc -n openshift-ingress
       ```
   1. DNS プロバイダーでカスタム・ドメインを作成します。
           クラスター内の複数のサービスに同じサブドメインを使用する場合は、ワイルドカード・サブドメイン (`*.example.com` など) を登録できます。
   {: tip}
   
   1. IP アドレスを A レコードとして追加して、カスタム・ドメインを Ingress コントローラーのパブリック IP アドレスにマップします。
   
   

3. アプリが必要とする TLS 終端処理のタイプに基づいて、経路をセットアップします。 カスタムドメインをお持ちでない場合は、「 --hostname 」オプションを含めないでください。 経路ホスト名は、<service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud という形式で生成されます。 ワイルドカード・サブドメインを登録した場合は、作成した経路ごとに固有のサブドメインを指定します。 例えば、この経路に --hostname svc1.example.com を指定し、他の経路に --hostname svc2.example.com を指定できます。

   • シンプル:

       oc expose service <app_service_name> [--hostname <subdomain>]
       ```
   * パススルー:
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
       ```
       HTTP/2 接続を処理する必要がある場合: 経路を作成した後、`oc edit route <app_service_name>` を実行し、経路の `targetPort` 値を `https` に変更します。 `curl -I --http2 https://<route> --insecure` を実行して、経路をテストできます。
   * Edge：カスタムドメインを使用する場合は、 `--hostname`、 `--cert`、 `--key` の各オプションを指定し、必要に応じて `--ca-cert` オプションも指定してください。 TLS の証明書要件に関する詳細については、 [Red Hat OpenShift のエッジルートに関するドキュメント](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}を参照してください。
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * 再暗号化：カスタムドメインを使用する場合は、 `--hostname`、 `--cert`、 `--key` の各オプションを指定し、必要に応じて `--ca-cert` オプションも指定してください。 TLS の証明書要件に関する詳細については、「 [Red Hat OpenShift の再暗号化ルート」に関するドキュメントを](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}参照してください。
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

4. アプリ・サービスの経路が作成されたことを確認します。

   oc get routes
   

5. オプション： オプションの設定でデフォルトのルーティングルールをカスタマイズします。 たとえば、ルート固有の HAProxy アノテーションを使用することができます。

プライベート・クラウド・サービス・エンドポイントしかない VPC クラスターでパブリック経路をセットアップする

クラスターが VPC インフラストラクチャー上に作成され、クラスター作成時にプライベート・クラウド・サービス・エンドポイントのみを有効にした場合、デフォルトではプライベート・ルーターのみを使用してクラスターが作成されます。 アプリをパブリックに公開するには、まずパブリック IngressController リソースを作成し、それをサブドメインで構成する必要があります。 Ingress オペレーターは、IngressController に基づいて新しいパブリック Ingress コントローラーを自動的に作成して構成します。これを使用して、アプリのパブリック経路を作成できます。

以下の手順で IngressController リソースを作成したとしても、IngressController は必要な Ingress コントローラーを作成して構成するためにのみ必要であることに注意してください。 Ingress コントローラーが作成されたら、Ingress コントローラーを直接使用して経路を作成します。

1. Ingress コントローラー用に使用するドメインを準備します。

   • カスタム・ドメイン: カスタム・ドメインを登録するには、ドメイン・ネーム・サービス (DNS) プロバイダーを利用するか、または IBM Cloud DNS を使用してください。 クラスター内の複数のサービスに同じサブドメインを使用する場合は、ワイルドカード・サブドメイン (*.example.com など) を登録できます。 カスタム・ドメインを使用する場合は、 IngressController 仕様でドメイン証明書も指定する必要があります。 詳しくは、 カスタム・デフォルト証明書の設定 を参照してください。
   • IBM 提供ドメイン:
     1. クラスター内の既存のサブドメインをリストします。 出力のサブドメイン列で、000<n> 値が最も高いサブドメインをコピーします。

        ibmcloud oc nlb-dns ls --cluster CLUSTER_NAME_OR_ID
        

        この出力例では、 mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud サブドメインの 000<n> 値が 0002 の最大値になっています。

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        

     2. コピーしたサブドメインで、サブドメインの 000<n> 値を 000<n+1> に変更します。 たとえば、「 mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud 」というサブドメインは、「 mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud 」に変更されます。 後の手順でこのサブドメインを登録します。

2. 手順 1 のドメインを指定して、パブリック Ingress コントローラーを構成する YAML ファイルを作成します。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: public
     namespace: openshift-ingress-operator
   spec:
     # defaultCertificate: If you are using a custom domain, specify the domain certificate
       # name: custom-certs-default
     replicas: 2
     domain: <domain>
     endpointPublishingStrategy:
       loadBalancer:
         scope: External
       type: LoadBalancerService
   

3. クラスターの openshift-ingress-operator 名前空間に IngressController リソースを作成します。 IngressController を作成すると、IngressController の設定に基づいて、パブリック Ingress コントローラーが自動的に作成され、openshift-ingress 名前空間にデプロイされます。 さらに、Ingress コントローラーを公開するために Ingress コントローラー・サービスが作成されます。

   oc create -f public.yaml -n openshift-ingress-operator
   

4. ** サービスの **EXTERNAL IProuter-public フィールドで VPC ホスト名を確認します。 VPC クラスターでは、ルーター・サービスの外部 IP アドレスは浮動アドレスであるため、VPC で割り当てられるホスト名が代わりに使用されます。

   oc get svc router-public -n openshift-ingress
   

   出力例

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
   router-public                LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
   

5. ステップ 1 で選択したドメインにサービスの VPC ホスト名を登録します。 このステップにより、Ingress コントローラー・サービスの IP アドレス (VPC ホスト名のまま) が、Ingress コントローラー用に選択したドメインに登録されます。

   • カスタム・ドメイン: DNS プロバイダーと連携して、サービスの VPC ホスト名を、カスタム・ドメインにマップする CNAME として追加します。
   • IBM 提供のドメイン: サービスの VPC ホスト名を DNS に登録します。 以下のコマンドを実行すると、ステップ 2 で指定したサブドメインが自動的に生成され、Ingress コントローラー・サービスに登録されます。

       ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
       ```
   

6. オプション: 特定の経路が特定の Ingress コントローラーによって処理されるように Ingress コントローラー・シャーディングを使用する場合 (例えば、プライベート経路がプライベート・ルーターにのみ許可されるようにする場合) は、経路ラベルまたは名前空間ラベルのいずれかを使用してシャーディング方式を指定できます。 作成時にセレクターを追加するには、spec の下の ingresscontroller yaml にそのセレクターを含めます。 例えば、Ingress コントローラーがラベル type=sharded の Ingress/経路のみを処理できるようにするには、routeSelector を追加します。 詳しくは、 Ingress コントローラーのシャーディングを参照してください。

     routeSelector:
       matchLabels:
         type: sharded
   

   1. 既存の Ingress コントローラーにセレクターを追加するには、Ingress コントローラーのリストを取得します。

       oc get ingresscontroller -n openshift-ingress-operator
       ```
   1. シャーディングを使用する Ingress コントローラーにセレクターを追加します。
   
   ```sh {: pre}
       oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
       ```
   
   1. セレクターはデフォルトの IngressController に追加されないため、すべての経路は引き続きクラスター上のデフォルトの Ingress コントローラーに受け入れられます。 この動作を変更するには、関連する経路または名前空間ラベル・セレクターを使用できます。 例えば、ラベル `type=sharded` を持つ ingress/経路をスキップするようにデフォルト・ルーターを調整するには、以下のパッチ・コマンドを実行します。
   ```sh {: pre}
       oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
       ```
       クラスター上のいくつかの経路と Ingresses は、デフォルトのパブリック Ingress コントローラーに依存します。 デフォルトのIngressコントローラーを編集する前に、変更内容が正しいことを確認してください。 詳しくは、 [Ingress コントローラーのシャーディング](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/networking_overview/index#nw-ingress-sharding_configuring-ingress){: external}を参照してください。
       {: note}
   
   
   

7. アプリのデプロイメント用の Kubernetes ClusterIP サービスを作成します。 サービスは、Ingress コントローラーがトラフィックを送信できるアプリの内部 IP アドレスを提供します。

   oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
   

8. アプリが必要とする TLS 終端処理のタイプに基づいて、経路をセットアップします。 --hostname オプションを指定しない場合、ルートのホスト名は <app_service_name>-<app_project>.<router-subdomain> という形式で自動的に生成されます。

   • シンプル:

       oc expose service <app_service_name> [--hostname <subdomain>]
       ```
   * パススルー:
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
       ```
       HTTP/2 接続を処理する必要がある場合: 経路を作成した後、`oc edit route <app_service_name>` を実行し、経路の `targetPort` 値を `https` に変更します。 `curl -I --http2 https://<route> --insecure` を実行して、経路をテストできます。
   * Edge：カスタムドメインを使用する場合は、 `--hostname`、 `--cert`、 `--key` の各オプションを指定し、必要に応じて `--ca-cert` オプションも指定してください。 TLS の証明書要件に関する詳細については、 [Red Hat OpenShift のエッジルートに関するドキュメント](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}を参照してください。
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * 再暗号化：カスタムドメインを使用する場合は、 `--hostname`、 `--cert`、 `--key` の各オプションを指定し、必要に応じて `--ca-cert` オプションも指定してください。 TLS の証明書要件に関する詳細については、「 [Red Hat OpenShift の再暗号化ルート」に関するドキュメントを](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}参照してください。
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

9. アプリの経路が作成されたことを確認します。

   oc get routes
   

10. オプション: オプションの構成を使用して、パブリック Ingress コントローラーのルーティング・ルールをカスタマイズします。 たとえば、ルート固有の HAProxy アノテーションを使用することができます。

11. 同じサブドメインを使用してさらに多くのアプリの経路を作成するには、同じパブリック Ingress コントローラーによって経路が生成されるようにステップ 7 から 10 を繰り返すことができます。 別のサブドメインを使用してさらに多くのアプリの経路を作成する場合は、このセクションのすべてのステップを繰り返して、別のドメインを使用する新しいパブリック Ingress コントローラーを作成します。

パブリック・クラウド・サービス・エンドポイントがあるクラシック・クラスターまたは VPC クラスターでプライベート経路をセットアップする

クラスターがクラシック・インフラストラクチャー上で作成されている場合、またはVPCインフラストラクチャ上で作成され、かつクラスター作成時にパブリッククラウドサービスエンドポイントを有効にした場合、そのクラスターはデフォルトでパブリックIngressコントローラーのみが設定された状態で作成されます。 アプリをプライベートに公開するには、まずプライベート IngressController リソースを作成し、サブドメインを使用してコントローラーを構成する必要があります。 Ingress オペレーターは、新しいプライベート Ingress コントローラーを自動的に作成して構成します。このコントローラーを使用して、アプリのプライベート経路を作成できます。

以下の手順で IngressController リソースを作成しても、IngressController リソースは必要な Ingress コントローラーの作成と構成にのみ必要であることに注意してください。 Ingress コントローラーが作成されたら、ルーターを直接使用して経路を作成します。

1. Ingress コントローラー用に使用するドメインを準備します。

   • カスタム・ドメイン、クラシック・クラスターまたは VPC クラスター: カスタム・ドメインを登録するには、ドメイン・ネーム・サービス (DNS) プロバイダーを利用するか、または IBM Cloud DNS を使用してください。 クラスター内の複数のサービスに同じサブドメインを使用する場合は、ワイルドカード・サブドメイン (*.example.com など) を登録できます。
   • IBM 提供ドメイン、VPC クラスターのみ:
     1. クラスター内の既存のサブドメインをリストします。 出力のサブドメイン列で、000<n> 値が最も高いサブドメインをコピーします。

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        この出力例では、 mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud サブドメインの 000<n> 値が 0002 の最大値になっています。

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        

     2. コピーしたサブドメインで、サブドメインの 000<n> 値を 000<n+1> に変更します。 たとえば、「 mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud 」というサブドメインは、「 mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud 」に変更されます。 後の手順でこのサブドメインを登録します。

2. 手順 1 のドメインを指定して、プライベート Ingress コントローラーを構成する構成ファイルを作成します。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: private
     namespace: openshift-ingress-operator
   spec:
     replicas: 2
     domain: <domain>
     endpointPublishingStrategy:
       loadBalancer:
         scope: Internal
       type: LoadBalancerService
   

3. クラスターの openshift-ingress-operator 名前空間に IngressController リソースを作成します。 IngressController リソースを作成すると、IngressController の設定に基づいて、プライベート Ingress コントローラーが自動的に作成され、openshift-ingress 名前空間にデプロイされます。 さらに、Ingress コントローラー・サービスが作成され、IP アドレス (クラシック・クラスター) または VPC ホスト名 (VPC クラスター) を使用して Ingress コントローラーが公開されます。

   oc create -f private.yaml -n openshift-ingress-operator
   

4. ** サービスの **EXTERNAL IProuter-private フィールドで IP アドレスまたは VPC ホスト名を確認します。

   oc get svc router-private -n openshift-ingress
   

   クラシック・クラスターの出力例:

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
   router-private               LoadBalancer   172.21.57.132    10.XX.XX.XX    80/TCP,443/TCP,1940/TCP      3m
   

   VPC クラスターの出力例:

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
   router-private               LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
   

5. 手順 1 で選択したドメインに、サービスの外部 IP アドレスまたは VPC ホスト名を登録します。

   • カスタム・ドメイン、クラシック・クラスターまたは VPC クラスター: DNS プロバイダーと連携して、サービスの外部 IP アドレスを、カスタム・ドメインにマップする A レコードとして追加するか (クラシック・クラスターの場合)、VPC ホスト名を、カスタム・ドメインにマップする CNAME として追加します (VPC クラスターの場合)。
   • IBM 提供ドメイン、VPC クラスターのみ: サービスの VPC ホスト名を DNS に登録します。 以下のコマンドを実行すると、ステップ 2 で指定したサブドメインが自動的に生成され、Ingress コントローラー・サービスに登録されます。

       ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
       ```
   

6. オプション: 特定の経路が特定の Ingress コントローラーによって処理されるように Ingress コントローラー・シャーディングを使用する場合 (例えば、プライベート経路がプライベート・ルーターにのみ許可されるようにする場合) は、経路ラベルまたは名前空間ラベルのいずれかを使用してシャーディング方式を指定できます。 作成時にセレクターを追加するには、spec の下の ingresscontroller yaml にそのセレクターを含めます。 例えば、Ingress コントローラーがラベル type=sharded の Ingress/経路のみを処理できるようにするには、routeSelector を追加します。 詳しくは、 Ingress コントローラーのシャーディングを参照してください。

     routeSelector:
       matchLabels:
         type: sharded
   

   1. 既存の Ingress コントローラーにセレクターを追加するには、Ingress コントローラーのリストを取得します。

       oc get ingresscontroller -n openshift-ingress-operator
       ```
   1. シャーディングを使用する Ingress コントローラーにセレクターを追加します。
   
   ```sh {: pre}
       oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
       ```
   
   1. セレクターはデフォルトの IngressController に追加されないため、すべての経路は引き続きクラスター上のデフォルトの Ingress コントローラーに受け入れられます。 この動作を変更するには、関連する経路または名前空間ラベル・セレクターを使用できます。 例えば、ラベル `type=sharded` を持つ ingress/経路をスキップするようにデフォルト・ルーターを調整するには、以下のパッチ・コマンドを実行します。
   ```sh {: pre}
       oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
       ```
   

7. アプリのデプロイメント用の Kubernetes ClusterIP サービスを作成します。 サービスは、Ingress コントローラーがトラフィックを送信できるアプリの内部 IP アドレスを提供します。

   oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
   

8. アプリが必要とする TLS 終端処理のタイプに基づいて、経路をセットアップします。 ステップ 5 でセットアップしたホスト名を指定してください。

   • シンプル:

       oc expose service <app_service_name> --hostname <subdomain>
       ```
   * パススルー:
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> --hostname <subdomain>
       ```
       HTTP/2 接続を処理する必要がある場合: 経路を作成した後、`oc edit route <app_service_name>` を実行し、経路の `targetPort` 値を `https` に変更します。 `curl -I --http2 https://<route> --insecure` を実行して、経路をテストできます。
   * Edge：カスタムドメインを使用する場合は、 `--cert` および `--key` オプションを含め、必要に応じて `--ca-cert` オプションも指定してください。 TLS の証明書要件に関する詳細については、 [Red Hat OpenShift のエッジルートに関するドキュメント](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}を参照してください。
   ```sh {: pre}
       oc create route edge --service <app_service_name> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * 再暗号化：カスタムドメインを使用する場合は、 `--cert` および `--key` オプションを指定し、必要に応じて `--ca-cert` オプションも指定してください。 TLS の証明書要件に関する詳細については、「 [Red Hat OpenShift の再暗号化ルート」に関するドキュメントを](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}参照してください。
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

9. アプリの経路が作成されたことを確認します。

   oc get routes
   

10. オプション: オプションの構成を使用して、プライベート Ingress コントローラーのルーティング・ルールをカスタマイズします。 たとえば、ルート固有の HAProxy アノテーションを使用することができます。

11. 同じサブドメインを使用してさらに多くのアプリの経路を作成するには、ステップ 7 から 10 を繰り返して、同じプライベート Ingress コントローラーによって経路が生成されるようにします。 別のサブドメインを使用してさらに多くのアプリの経路を作成する場合は、このセクションのすべてのステップを繰り返して、新しいプライベート Ingress コントローラーを作成します。

プライベート・クラウド・サービス・エンドポイントしかない VPC クラスターでプライベート経路をセットアップする

クラスターが VPC インフラストラクチャー上に作成され、クラスター作成時にプライベート・クラウド・サービス・エンドポイントのみを有効にした場合は、デフォルトでプライベート Ingress コントローラーを使用してクラスターが作成されます。 この Ingress コントローラーを使用して、アプリのプライベート経路を作成できます。

1. アプリのデプロイメント用の Kubernetes ClusterIP サービスを作成します。 サービスは、Ingress コントローラーがトラフィックを送信できるアプリの内部 IP アドレスを提供します。

   oc expose deploy <app_deployment_name> --name my-app-svc
   

2. アプリのドメインを選択します。

   • IBM 提供ドメイン: カスタム・ドメインが不要な場合は、<service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud という形式の経路サブドメインが自動的に生成されます。
   • カスタム・ドメイン: カスタム・ドメインを指定する場合は、お客様の DNS プロバイダーまたは IBM Cloud® Internet Services を使用します。

     1. 外部 IP 列の各ゾーンのプライベート Ingress コントローラー・サービスの外部 IP アドレスを取得します。 ワーカー・ノードがある最初のゾーンの Ingress コントローラー・サービスの名前は常に router-default になり、その後クラスターに追加するゾーンの Ingress コントローラー・サービスの名前は router-dal12 になることに注意してください。

        oc get svc -n openshift-ingress
        

     2. DNS プロバイダーでカスタム・ドメインを作成します。 クラスター内の複数のサービスに同じサブドメインを使用する場合は、ワイルドカード・サブドメイン (*.example.com など) を登録できます。

     3. IP アドレスを A レコードとして追加して、カスタム・ドメインを Ingress コントローラー・サービスのプライベート IP アドレスにマップします。

3. アプリが必要とする TLS 終端のタイプに基づいて経路をセットアップします。 カスタムドメインをお持ちでない場合は、「 --hostname 」オプションを含めないでください。 経路サブドメインは、<service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud という形式で自動的に生成されます。 ワイルドカード・サブドメインを登録した場合は、作成した経路ごとに固有のサブドメインを指定します。 例えば、この経路に --hostname svc1.example.com を指定し、他の経路に --hostname svc2.example.com を指定できます。

   • シンプル:

       oc expose service <app_service_name> [--hostname <subdomain>]
       ```
   * パススルー:
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
       ```
       HTTP/2 接続を処理する必要がある場合: 経路を作成した後、`oc edit route <app_service_name>` を実行し、経路の `targetPort` 値を `https` に変更します。 `curl -I --http2 https://<route> --insecure` を実行して、経路をテストできます。
   
   * Edge：カスタムドメインを使用する場合は、 `--hostname`、 `--cert`、 `--key` の各オプションを指定し、必要に応じて `--ca-cert` オプションも指定してください。 TLS の証明書要件に関する詳細については、 [Red Hat OpenShift のエッジルートに関するドキュメント](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}を参照してください。
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * 再暗号化：カスタムドメインを使用する場合は、 `--hostname`、 `--cert`、 `--key` の各オプションを指定し、必要に応じて `--ca-cert` オプションも指定してください。 TLS の証明書要件に関する詳細については、「 [Red Hat OpenShift の再暗号化ルート」に関するドキュメントを](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}参照してください。
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

4. アプリ・サービスの経路が作成されたことを確認します。

   oc get routes
   

5. オプション： オプションの設定でデフォルトのルーティングルールをカスタマイズします。 たとえば、ルート固有の HAProxy アノテーションを使用することができます。