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

経路を使用して、Red Hat® OpenShift® on IBM Cloud® クラスター内のサービスをルーターの外部 IP アドレスで公開します。

この情報は、Red Hat OpenShift バージョン 4 を実行するクラスターを対象としています。

Red Hat OpenShift の経路と Ingress のどちらを使用すべきかわからない場合は、ロード・バランシング・ソリューションの選択を参照してください。

概要

デフォルトでは、 Red Hat OpenShift Ingressコントローラがクラスタに配備され、外部ネットワークトラフィックのイングレスエンドポイントとして機能します。

Red Hat OpenShift Ingressコントローラーを使って、アプリのルートを作成することができます。経路には、外部クライアントがアプリに要求を送信するために使用できる、Ingress コントローラー・サブドメインからパブリックまたはプライベートにアクセス可能なホスト名が割り当てられます。ホスト名を保護するために、Ingress コントローラーの TLS 証明書を使用して、保護されていない経路または保護された経路を作成することを選択できます。外部要求がホスト名に到達すると、Ingress コントローラーは要求をプロキシー処理し、それをアプリが listen するプライベート IP アドレスに転送します。

デフォルトで作成される Ingress コントローラーのタイプは、クラスターのインフラストラクチャー・プロバイダーとサービス・エンドポイントのセットアップによって異なります。

パブリック・クラウド・サービス・エンドポイントを持つクラシック・クラスタ/VPCクラスタ ：デフォルトでは、クラスタはパブリックIngressコントローラで作成されます。 Ingress コントローラーは、パブリックでアクセス可能な経路をアプリに割り当て、パブリック・ホスト・ネットワーク・インターフェースでアプリへの要求を listen します。要求を受信すると、Ingress コントローラーは、アプリが listen するプライベート IP アドレスに要求を送信します。代わりにアプリをプライベートに公開する場合は、まずプライベート Ingress コントローラーを作成してから、プライベート経路を作成する必要があります。
プライベート・クラウド・サービス・エンドポイントのみのVPCクラスター ：クラスターはデフォルトでプライベートIngressコントローラーで作成されます。 Ingress コントローラーは、プライベートでアクセス可能な経路をアプリに割り当て、プライベート・ホスト・ネットワーク・インターフェースで listen します。プライベート経路で公開されたアプリには、プライベート VPC ネットワークに接続しているクライアントしかアクセスできません。代わりにアプリをパブリックに公開する場合は、まずパブリック Ingress コントローラーを作成してから、パブリック経路を作成する必要があります。

複数ゾーン・クラスターがある場合は、1 つの高可用性 Ingress コントローラーがクラスターにデプロイされ、各ゾーンに 1 つの Ingress コントローラー・サービスが作成されます。 Ingress コントローラーの 2 つのレプリカを正常にデプロイして更新できるように、ゾーンごとにワーカー・ノードが 2 つ必要です。ワーカー・ノードがある最初のゾーンの Ingress コントローラー・サービスの名前は常に router-default になり、その後クラスターに追加するゾーンの Ingress コントローラー・サービスの名前は router-dal12 になることに注意してください。

クラスターの各ゾーンの Ingress コントローラー・サービスを確認するには、oc get svc -n openshift-ingress を実行します。
クラスターの Ingress コントローラー・サブドメインと、各ゾーンの Ingress コントローラー・サービスの IP アドレスを確認するには、ibmcloud oc nlb-dns ls -c <cluster_name_or_ID> を実行し、<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud のような形式のサブドメインを探します。

VPC インフラストラクチャーのダッシュボードでは、VPC ロード・バランサーから正常と報告されるのは、Ingress コントローラーのレプリカ・ポッドを実行する 2 つのワーカー・ノードだけです。この 2 つのワーカー・ノードが VPC ロード・バランサーのリスナーとして構成されているためです。正常と報告されるのはリスナーのワーカー・ノードだけですが、リスナーのバックエンド・プールのワーカー・ノードには Red Hat OpenShift on IBM Cloud によって最新の情報が提供されるので、クラスター内のすべてのワーカー・ノードが VPC ロード・バランサーから要求を受信し続けることができます。

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

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

ルーターを使用することで、シングルゾーンのクラスターRed Hat OpenShiftでアプリを公開する*" caption-side="bottom"}を使用することで、シングルゾーンのクラスター*でアプリを {: caption="する

アプリに対する要求では、アプリにセットアップした経路のホスト名を使用します。
DNS サービスが、サブドメインをルーター・サービスのポータブル・パブリック IP アドレスに解決します。
ルーターは要求を受け取り、それをプライベート・ネットワークを介してアプリ・ポッドのプライベート IP アドレスに転送します。要求パッケージのソース IP アドレスが、ルーター・ポッドが実行されるワーカー・ノードのパブリック IP アドレスに変更されます。複数のアプリ・インスタンスがクラスターにデプロイされている場合、ルーターは、それらのアプリ・ポッド間に要求を送信します。
アプリが応答パケットを返す際には、クライアント要求を転送したルーターが存在するワーカー・ノードの IP アドレスが使用されます。そして、ルーターがロード・バランサー・サービスを介してクライアントに応答パケットを送信します。

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

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

ルーターを使用してマルチゾーン Red Hat OpenShift クラスタ内のアプリを公開 — ルーターを使用してマルチゾーンクラスタ内のアプリを公開

アプリに対する要求では、アプリにセットアップした経路のホスト名を使用します。
DNS サービスが、その経路のサブドメインを、マルチゾーン・ロード・バランサー (MZLB) から正常と報告されたルーター・サービスのポータブル・パブリック IP アドレスに解決します。 MZLB は、クラスターの各ゾーンで、ルーターを公開するサービスのポータブル・パブリック IP アドレスを継続的に検査します。ラウンドロビン・サイクルでさまざまなゾーンのルーター・サービスが要求を処理します。
解決されたルーター・サービスの IP アドレスに基づいて、ルーターが要求を受信します。
ルーターがプライベート・ネットワーク経由でアプリ・ポッドのプライベート IP アドレスに要求を転送します。要求パッケージのソース IP アドレスが、ルーター・ポッドが実行されるワーカー・ノードのパブリック IP アドレスに変更されます。各ルーターは、同じゾーンに属するアプリ・インスタンスへの要求と、他のゾーンのアプリ・インスタンスへの要求を送信します。さらに、1 つのゾーンに複数のアプリ・インスタンスがデプロイされている場合は、ルーターがアプリ・ポッド間で要求を転送します。
アプリが応答パケットを返す際には、クライアント要求を転送したルーターが存在するワーカー・ノードの IP アドレスが使用されます。そして、ルーターがロード・バランサー・サービスを介してクライアントに応答パケットを送信します。

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

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

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

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

アプリに対する要求では、アプリにセットアップした経路のホスト名を使用します。
DNS サービスは、経路サブドメインを、Ingress コントローラーに割り当てられた VPC ロード・バランサーのホスト名に解決します。 VPC クラスターでは、Ingress コントローラー・サービスの外部 IP アドレスは浮動アドレスであり、VPC 割り当てのホスト名の背後に保持されます。
VPC ロード・バランサーは、VPC ホスト名を、正常と報告された Ingress コントローラー・サービスの使用可能な外部 IP アドレスに解決します。 VPC ロード・バランサーは、クラスター内の各ゾーンで Ingress コントローラーを公開するサービスの外部 IP アドレスを継続的に検査します。
解決された IP アドレスに基づいて、VPC ロード・バランサーは要求を Ingress コントローラー・サービスに送信します。
Ingress コントローラーは、プライベート・ネットワークを介してアプリ・ポッドのプライベート IP アドレスに要求を転送します。要求パケットのソース IP アドレスは、Ingress コントローラー・ポッドが実行されるワーカー・ノードの IP アドレスに変更されます。各 Ingress コントローラーは、独自のゾーン内のアプリ・インスタンスと、他のゾーン内のアプリ・インスタンスに要求を送信します。さらに、複数のアプリ・インスタンスが 1 つのゾーンにデプロイされている場合、Ingress コントローラーはアプリ・ポッド間で要求を交換します。
アプリは、応答パケットを返すときに、クライアント要求を転送した Ingress コントローラーが存在するワーカー・ノードの IP アドレスを使用します。その後、Ingress コントローラーは、VPC ロード・バランサーを介して応答パケットをクライアントに送信します。

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

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

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

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

プライベートの VPC ネットワークに接続したクライアントが、アプリのプライベート経路を使用してアプリに要求を送信します。例えば、仮想プライベート・クラウド VPN、IBM Cloud Transit Gateway、IBM Cloud Direct Link などを使用して、オンプレミスのネットワーク、別の VPC、または IBM Cloud クラシック・インフラストラクチャーから、クラスターで実行されているアプリに要求を送信することができます。
DNS サービスは、経路サブドメインを、Ingress コントローラーに割り当てられた VPC ロード・バランサーのホスト名に解決します。 VPC クラスターでは、Ingress コントローラー・サービスの IP アドレスは浮動アドレスであり、VPC 割り当てのホスト名の後に保持されます。経路のサブドメインの DNS レコードはパブリック DNS システムに登録されていますが、DNS 解決サーバーに到達できるのは VPC からであることに注意してください。
プライベート VPC ロード・バランサーは、VPC ホスト名を、正常と報告された Ingress コントローラーのゾーン内の使用可能なプライベート IP アドレスに解決します。 VPC ロード・バランサーは、クラスター内の各ゾーンで Ingress コントローラーを公開するサービスの IP アドレスを継続的に検査します。
解決された IP アドレスに基づいて、VPC ロード・バランサーは要求を Ingress コントローラー・サービスに送信します。
Ingress コントローラーは、プライベート・ネットワークを介してアプリ・ポッドのプライベート IP アドレスに要求を転送します。要求パケットのソース IP アドレスは、Ingress コントローラー・ポッドが実行されるワーカー・ノードの IP アドレスに変更されます。各 Ingress コントローラーは、独自のゾーン内のアプリ・インスタンスと、他のゾーン内のアプリ・インスタンスに要求を送信します。さらに、複数のアプリ・インスタンスが 1 つのゾーンにデプロイされている場合、Ingress コントローラーはアプリ・ポッド間で要求を交換します。
アプリは、応答パケットを返すときに、クライアント要求を転送した Ingress コントローラーが存在するワーカー・ノードの IP アドレスを使用します。その後、Ingress コントローラーは、VPC ロード・バランサーを介して、IBM Cloud VPC VPN、Transit Gateway、または Direct Link を介してクライアントに応答パケットを送信します。

経路のタイプと TLS 終端

Red Hat OpenShift では、アプリが必要とする TLS 終端処理のタイプに基づいて、4 つのタイプの経路を利用できます。どの経路タイプも、パブリックおよびプライベートの経路に対応しています。

TLS 終端処理に基づく経路のタイプ
経路タイプ	ユース・ケース
シンプル	TLS 暗号化が必要ない場合は、暗号化されていない HTTP トラフィックを処理するための単純な経路を作成します。
Passthrough	クライアントからアプリ・ポッドに TLS 接続を中断なしで受け渡す場合は、パススルー経路を作成してください。ルーターは暗号化 HTTPS トラフィックの TLS 終端処理に関与しないので、アプリ・ポッドが TLS 接続を終端する必要があります。このタイプは、HTTP/2 にも HTTP でない TLS エンドポイントにも使用できます。
エッジ	暗号化されていない HTTP エンドポイントでアプリ・ポッドを公開するものの、暗号化された HTTPS トラフィックを処理する必要がある場合は、エッジ経路を作成してください。クライアントとルーター・サービスの間の TLS 接続は終端され、ルーター・サービスとアプリ・ポッドの間の接続は暗号化されません。詳細については、 Red Hat OpenShift のエッジルートのドキュメントを参照してください。
再暗号化	暗号化された HTTPS エンドポイントでアプリ・ポッドを公開し、HTTPS トラフィックを処理する必要がある場合は、再暗号化経路を作成してください。クライアントとルーター・サービスの間の TLS 接続は終端され、ルーター・サービスとアプリ・ポッドの間には新しい TLS 接続が作成されます。詳細については、 Red Hat OpenShift の再暗号化ルートに関するドキュメントを参照してください。

カスタム・ドメインを使用する必要がない場合は、IBM 提供の経路ホスト名を <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud の形式で使用できます。

Ingress コントローラーのヘルス・チェック

ネットワーク・ポリシーまたはその他のファイアウォール・ルールによるアクセスを許可して、Ingress コントローラー・サービスが Ingress コントローラーのヘルス・チェックによって到達できるようにします。

クラシック: Calico pre-DNAT ネットワーク・ポリシーまたは別のカスタム・ファイアウォールを使用してクラスターへの着信トラフィックをブロックする場合は、Red Hat OpenShift コントロール・プレーンおよび Akamai の IPv4 IP アドレスから Ingress コントローラー・サービスの IP アドレスへのポート 80 でのインバウンド・アクセスを許可して、Red Hat OpenShift コントロール・プレーンが Ingress コントローラーの正常性を検査できるようにする必要があります。たとえば、 Calico ポリシーを使用する場合は、 Calico pre-DNAT ポリシーを作成し、ポート 80 およびクラスタが配置されているリージョンのコントロールプレーンサブネットで Ingress コントローラーの健全性をチェックするために使用されるアカマイのソース IP アドレスから、Ingress コントローラーへのインバウンドアクセスを許可します。次のステップに進んで、Ingress コントローラーのサービス IP アドレスを取得します。

VPC: VPC セキュリティー・グループまたは VPC アクセス制御リスト (ACL) をセットアップしてクラスター・ネットワークを保護する場合、Red Hat OpenShift コントロール・プレーン IP アドレスからの必要なトラフィックを許可するルールを必ず作成してください。あるいは、Ingressコントローラのヘルスチェックのためにインバウンドトラフィックを許可するには、ポート80のすべての受信トラフィックを許可するルールを1つ作成します。

パブリック経路のセットアップ

クラスター内のアプリを公開するには、パブリック Ingress コントローラーを使用します。

パブリック経路をセットアップする方法は、クラスターのインフラストラクチャー・プロバイダーとサービス・エンドポイントのセットアップによって、次のように異なります。

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

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

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

アプリのデプロイメント用の Kubernetes ClusterIP サービスを作成します。サービスは、Ingress コントローラーがトラフィックを送信できるアプリの内部 IP アドレスを提供します。
```
oc expose deploy <app_deployment_name> --name my-app-svc
```
アプリのドメインを選択します。ルートURLは130文字以下である必要があります。IBM 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 アドレスにマップします。
アプリが必要とする 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>]
```
- パススルー:
```
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 を実行して、経路をテストできます。
- エッジ：カスタム・ドメインを使用する場合は、 --hostname、 --cert、 --key オプション、およびオプションで --ca-cert オプションを含めます。 TLS証明書の要件の詳細については、 Red Hat OpenShift エッジルートのドキュメントを参照してください。
```
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 re-encryptルートのドキュメントを参照してください。
```
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>]
```
アプリ・サービスの経路が作成されたことを確認します。
```
oc get routes
```
オプション：オプションの設定でデフォルトのルーティングルールをカスタマイズします。例えば、ルート固有の HAProxy アノテーションを使うことができる。

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

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

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

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 に変更される。後の手順でこのサブドメインを登録します。

手順 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

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

** サービスの **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

ステップ 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>
```
オプション: 特定の経路が特定の 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
```
2. シャーディングを使用する Ingress コントローラーにセレクターを追加します。
```
oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
```
3. セレクターはデフォルトの IngressController に追加されないため、すべての経路は引き続きクラスター上のデフォルトの Ingress コントローラーに受け入れられます。この動作を変更するには、関連する経路または名前空間ラベル・セレクターを使用できます。例えば、ラベル type=sharded を持つ ingress/経路をスキップするようにデフォルト・ルーターを調整するには、以下のパッチ・コマンドを実行します。
```
oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
```
  クラスター上のいくつかの経路と Ingresses は、デフォルトのパブリック Ingress コントローラーに依存します。デフォルトのIngressコントローラを編集する前に、変更が正しいことを確認する。詳しくは、 Ingress コントローラーのシャーディングを参照してください。
アプリのデプロイメント用の Kubernetes ClusterIP サービスを作成します。サービスは、Ingress コントローラーがトラフィックを送信できるアプリの内部 IP アドレスを提供します。
```
oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
```
アプリが必要とする TLS 終端処理のタイプに基づいて、経路をセットアップします。 --hostname オプションを付けない場合、ルートホスト名は <app_service_name>-<app_project>.<router-subdomain>.
- シンプル:
```
oc expose service <app_service_name> [--hostname <subdomain>]
```
- パススルー:
```
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 を実行して、経路をテストできます。
- エッジ：カスタム・ドメインを使用する場合は、 --hostname、 --cert、 --key オプション、およびオプションで --ca-cert オプションを含めます。 TLS証明書の要件の詳細については、 Red Hat OpenShift エッジルートのドキュメントを参照してください。
```
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 re-encryptルートのドキュメントを参照してください。
```
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>]
```
アプリの経路が作成されたことを確認します。
```
oc get routes
```
オプション: オプションの構成を使用して、パブリック Ingress コントローラーのルーティング・ルールをカスタマイズします。例えば、ルート固有の HAProxy アノテーションを使うことができる。
同じサブドメインを使用してさらに多くのアプリの経路を作成するには、同じパブリック Ingress コントローラーによって経路が生成されるようにステップ 7 から 10 を繰り返すことができます。別のサブドメインを使用してさらに多くのアプリの経路を作成する場合は、このセクションのすべてのステップを繰り返して、別のドメインを使用する新しいパブリック Ingress コントローラーを作成します。

プライベート経路のセットアップ

プライベート Ingress コントローラーを使用して、プライベート・ネットワーク上のクラスター内のアプリを公開します。

プライベート経路をセットアップする方法は、クラスターのインフラストラクチャー・プロバイダーとサービス・エンドポイントのセットアップによって、次のように異なります。

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

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

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

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

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 に変更される。後の手順でこのサブドメインを登録します。

手順 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

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

** サービスの **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

手順 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>
```
オプション: 特定の経路が特定の 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
```
2. シャーディングを使用する Ingress コントローラーにセレクターを追加します。
```
oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
```
3. セレクターはデフォルトの IngressController に追加されないため、すべての経路は引き続きクラスター上のデフォルトの Ingress コントローラーに受け入れられます。この動作を変更するには、関連する経路または名前空間ラベル・セレクターを使用できます。例えば、ラベル type=sharded を持つ ingress/経路をスキップするようにデフォルト・ルーターを調整するには、以下のパッチ・コマンドを実行します。
```
oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
```
アプリのデプロイメント用の Kubernetes ClusterIP サービスを作成します。サービスは、Ingress コントローラーがトラフィックを送信できるアプリの内部 IP アドレスを提供します。
```
oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
```
アプリが必要とする TLS 終端処理のタイプに基づいて、経路をセットアップします。ステップ 5 でセットアップしたホスト名を指定してください。
- シンプル:
```
oc expose service <app_service_name> --hostname <subdomain>
```
- パススルー:
```
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 を実行して、経路をテストできます。
- エッジ：カスタムドメインを使用する場合は、 --cert と --key オプション、およびオプションで --ca-cert オプションを含めます。 TLS証明書の要件の詳細については、 Red Hat OpenShift エッジルートのドキュメントを参照してください。
```
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 re-encryptルートのドキュメントを参照してください。
```
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>]
```
アプリの経路が作成されたことを確認します。
```
oc get routes
```
オプション: オプションの構成を使用して、プライベート Ingress コントローラーのルーティング・ルールをカスタマイズします。例えば、ルート固有の HAProxy アノテーションを使うことができる。
同じサブドメインを使用してさらに多くのアプリの経路を作成するには、ステップ 7 から 10 を繰り返して、同じプライベート Ingress コントローラーによって経路が生成されるようにします。別のサブドメインを使用してさらに多くのアプリの経路を作成する場合は、このセクションのすべてのステップを繰り返して、新しいプライベート Ingress コントローラーを作成します。

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

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

アプリのデプロイメント用の Kubernetes ClusterIP サービスを作成します。サービスは、Ingress コントローラーがトラフィックを送信できるアプリの内部 IP アドレスを提供します。
```
oc expose deploy <app_deployment_name> --name my-app-svc
```
アプリのドメインを選択します。
- 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 アドレスにマップします。
アプリが必要とする 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>]
```
- パススルー:
```
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 を実行して、経路をテストできます。
- エッジ：カスタム・ドメインを使用する場合は、 --hostname、 --cert、 --key オプション、およびオプションで --ca-cert オプションを含めます。 TLS証明書の要件の詳細については、 Red Hat OpenShift エッジルートのドキュメントを参照してください。
```
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 re-encryptルートのドキュメントを参照してください。
```
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>]
```
アプリ・サービスの経路が作成されたことを確認します。
```
oc get routes
```
オプション：オプションの設定でデフォルトのルーティングルールをカスタマイズします。例えば、ルート固有の HAProxy アノテーションを使うことができる。

クラシック・クラスター内の VLAN 間での Ingress コントローラー・サービスの移動

ワーカーノードの VLAN 接続を変更すると、ワーカーノードは新しい VLAN に接続され、新しいパブリックまたはプライベート IP アドレスが割り当てられます。ただし、Ingress コントローラー・サービスは、古い VLAN に属するサブネットから安定したポータブル・パブリック IP アドレスまたはプライベート IP アドレスを割り当てられるため、新しい VLAN に自動的にマイグレーションすることはできません。ワーカー・ノードと Ingress コントローラーが別々の VLAN に接続されている場合、Ingress コントローラーは着信ネットワーク・トラフィックをワーカー・ノード上のアプリ・ポッドに転送できません。 Ingress コントローラー・サービスを別の VLAN に移動するには、新しい VLAN 上に Ingress コントローラー・サービスを作成し、古い VLAN 上の Ingress コントローラー・サービスを削除する必要があります。

新規 VLAN 上に Ingress コントローラー・サービスを作成します。

新しい Ingress コントローラー・サービスの YAML 構成ファイルを作成します。 Ingress コントローラー・サービスのデプロイ先のゾーンを指定します。ファイルを router-new-<zone>.yaml として保存します。

パブリック Ingress コントローラー・サービス:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: <zone>
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: public
  finalizers:
  - service.kubernetes.io/load-balancer-cleanup
  labels:
    app: router
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
    router: router-default
  name: router-new-<zone>
  namespace: openshift-ingress
spec:
  externalTrafficPolicy: Local
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: http
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
  sessionAffinity: None
  type: LoadBalancer

プライベート Ingress コントローラー・サービス:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: <zone>
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
  finalizers:
  - service.kubernetes.io/load-balancer-cleanup
  labels:
    app: router
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: private
    router: router-private
  name: router-new-<zone>
  namespace: openshift-ingress
spec:
  externalTrafficPolicy: Local
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: http
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: private
  sessionAffinity: None
  type: LoadBalancer

新しい Ingress コントローラー・サービスを作成します。
```
oc apply -f router-new-<zone>.yaml -n openshift-ingress
```

新しい Ingress コントローラー・サービスの外部 IP アドレスを取得します。この IP アドレスは、新規 VLAN のサブネットのものです。

oc get svc router-new -n openshift-ingress

パブリック Ingress コントローラー・サービスの出力例:

NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                     AGE
router-new                   LoadBalancer   172.21.XX.XX     169.XX.XXX.XX   80:31049/TCP,443:30219/TCP                  2m

複数ゾーン・クラスター: 複数のゾーン内のワーカー・ノードの VLAN を変更した場合は、これらのステップを繰り返して、各ゾーン内の新しい VLAN 上に Ingress コントローラー・サービスを作成します。

Ingress コントローラーのホスト名をメモします。出力で、<cluster_name>-<random_hash>-0001.<region>.containers.appdomain.cloud のような形式のホスト名を探します。

ibmcloud oc nlb-dns ls -c <cluster_name_or_ID>

出力例

Hostname                                                                             IP(s)           Health Monitor   SSL Cert Status   SSL Cert Secret Name                            Secret Namespace
mycluster-35366fb2d3d90fd50548180f69e7d12a-0001.us-east.containers.appdomain.cloud   169.XX.XXX.XX   None             created           roks-ga-35366fb2d3d90fd50548180f69e7d12a-0001   default
...

ステップ 1 で確認した新しい Ingress コントローラー・サービスの IP アドレスを Ingress コントローラーのホスト名に追加します。ステップ1で複数のゾーンにサービスを作成した場合は、 --ip オプションを繰り返し、各IPアドレスを個別に含めます。
```
ibmcloud oc nlb-dns add -c <cluster_name_or_ID> --ip <new_IP> --nlb-host <subdomain>
```
これで、新しい VLAN 上の Ingress コントローラー・サービスがクラスター内のデフォルトの Ingress コントローラーのドメインに登録され、着信要求をアプリに転送できるようになりました。
古い VLAN 上の古い Ingress コントローラー・サービスの IP アドレスを取得します。 複数ゾーン・クラスター: 複数のゾーン内のワーカー・ノードの VLAN を変更した場合は、VLAN が変更された各ゾーンの Ingress コントローラー・サービスの IP アドレスを取得します。ワーカー・ノードがある最初のゾーンの Ingress コントローラー・サービスの名前は常に router-default であり、その後クラスターに追加するゾーンの Ingress コントローラー・サービスの名前は router-dal12 のようになります。
```
oc get svc -n openshift-ingress
```
マルチゾーン・クラスターの出力例:
```
NAME                          TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                      AGE
router-dal12                  LoadBalancer   172.21.190.62    169.XX.XX.XX     80:32318/TCP,443:30915/TCP   51d
router-default                LoadBalancer   172.21.47.119    169.XX.XX.XX     80:31311/TCP,443:32561/TCP   78d
router-internal-default       ClusterIP      172.21.51.30     <none>           80/TCP,443/TCP,1936/TCP      78d
```
ステップ 2 で確認した古い Ingress コントローラー・サービスの IP アドレスを Ingress コントローラーのホスト名から削除します。 マルチゾーン・クラスタ ：繰り返される --ip オプションに各IPアドレスを個別に含める。
```
ibmcloud oc nlb-dns rm classic -c <cluster_name_or_ID> --ip <old_IP> --nlb-host <hostname>
```
Ingress コントローラーのホスト名が新しい IP アドレスに登録されたことを確認します。 Ingress コントローラーのホスト名が新しいサービスの IP アドレスで更新された後は、Ingress コントローラーや経路の変更は必要はありません。
```
ibmcloud oc nlb-dns ls -c <cluster_name_or_ID>
```
古い VLAN 上の Ingress コントローラー・サービスを削除します。
```
oc delete svc <old_router_svc> -n openshift-ingress
```
オプション: 古い VLAN 上のサブネットが不要になった場合は、それらを削除できます。