Ingress オペレーター

Red Hat OpenShift Ingress オペレーターは、クラスター内のアプリケーションへのすべての受信トラフィックに適用されるルーティングルールを実装します。

Ingress コントローラーは、Ingress オペレーターによって管理されます。 クラスターの作成時に、デフォルトの Ingress コントローラーが、クラスターのデフォルトの Ingress サブドメインに <cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloudという形式で登録されます。 ルート・リソースを作成してこのサブドメインにアプリを登録すると、Ingress コントローラーは、このサブドメインを介したアプリへの要求がアプリ・ポッドに適切にプロキシーされるようにします。 クラスター内のデフォルトの Ingress コントローラーを表示するには、oc describe ingresscontroller/default -n openshift-ingress-operator を実行します。

別のドメインにアプリを登録する場合は、代わりとなるカスタム・ドメインのルーティング・ルールを実装したカスタム Ingress コントローラーを作成できます。

Ingress コントローラー

HAProxy ベースの Red Hat OpenShift Ingress コントローラーは IngressController ごとに 1 つ作成され、Ingress コントローラー・サービスはワーカー・ノードがあるゾーンごとに 1 つ作成されます。

Ingress オペレーターは、Ingress コントローラーで指定されているドメインと同じドメインを使用して Ingress コントローラーを構成します。 Ingress コントローラーは、そのドメインを介して着信する HTTP、HTTPS、または TCP サービス要求を listen します。 その後、Ingress コントローラーのロード・バランサー・サービス・コンポーネントは、Route リソースで定義され、Ingress コントローラーで実装されたルールに従って、そのアプリのポッドだけに要求を転送します。

マルチゾーン・クラスターの場合は、高可用性ルーターがクラスターに 1 つデプロイされ、マルチゾーン VPC ロード・バランサーを使用して構成されます。 Ingress コントローラーの 2 つのレプリカを正常にデプロイして更新できるように、ゾーンごとにワーカー・ノードが 2 つ必要です。

Ingress コントローラーを手動で作成する場合、Ingress コントローラーは、Ingress サブドメインにもクラスター内のアプリにも自動的に登録されません。

Route リソース

Route を使用してアプリを公開するには、アプリ用の Kubernetes サービスを作成し、Route リソースを定義してこのサービスを Ingress コントローラーに登録する必要があります。 Ingress リソースは、アプリの着信要求を転送する方法に関するルールを定義する Red Hat OpenShift リソースです。

Route リソースは、アプリ・サービスへのパスも指定します。 アプリ・サービスへのパスがクラスターの Ingress サブドメインに追加されて、固有のアプリ URL (mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1 など) が形成されます。

公開するアプリを入れるプロジェクトごとに 1 つの Route リソースが必要です。

• クラスター内のアプリがすべて同じプロジェクト内にある場合は、公開するアプリのルーティング・ルールを定義する Route リソースを 1 つ作成する必要があります。 ただし、同じプロジェクトに属するアプリが複数の異なるドメインを使用できるようにする場合は、ドメインごとに 1 つのリソースを作成します。
• クラスター内のアプリが異なるプロジェクトにある場合は、プロジェクトごとに 1 つの Route リソースを作成して、アプリのルーティング・ルールを定義する必要があります。

詳しくは、1 つのプロジェクトを使用する場合と複数のプロジェクトを使用する場合のネットワーキングの計画を参照してください。

アプリのルーティング・ルールをカスタマイズする場合は、アプリのトラフィックを管理する経路固有の HAProxy アノテーションを使用できます。 これらのサポートされるアノテーションの形式は、haproxy.router.openshift.io/<annotation> または router.openshift.io/<annotation> です。 IBM Cloud Kubernetes Service アノテーション (ingress.bluemix.net/<annotation>) および NGINX アノテーション (nginx.ingress.kubernetes.io/<annotation>) は、Red Hat OpenShift バージョン 4 の Ingress コントローラーまたは Route リソースではサポートされない点に注意してください。

単一ゾーン・クラスター

次の図は、インターネットから単一ゾーンのクラシック・クラスター内のアプリへの通信を Ingress が転送する方法を示しています。

1. ユーザーがアプリの URL にアクセスしてアプリに要求を送信します。 この URL は、クラスターの Ingress サブドメインに、公開されたアプリの Ingress リソース・パスを付加したものです (例: mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp)。

2. DNS システム・サービスが、URL のサブドメインを、クラスター内の Ingress コントローラーを公開しているロード・バランサーのポータブル・パブリック IP アドレスに解決します。

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

4. Ingress コントローラーは、 Ingress コントローラーで実装されたルーティング・ルールの中に myapp パスのルーティング・ルールがあるかどうかを検査します。 一致するルールが見つかると、要求は、Ingress コントローラーで定義したルールと Route リソースに従って、アプリがデプロイされているポッドにプロキシー処理されます。 パケットのソース IP アドレスが、Ingress コントローラー・ポッドが実行されるワーカー・ノードの IP アドレスに変更されます。 複数のアプリ・インスタンスがクラスターにデプロイされている場合、Ingress コントローラーはアプリ・ポッド間で要求のロード・バランシングを行います。

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

複数ゾーン・クラスター

次の図は、インターネットから複数ゾーンのクラシック・クラスター内のアプリへの通信を Ingress が転送する方法を示しています。

1. ユーザーがアプリの URL にアクセスしてアプリに要求を送信します。 この URL は、クラスターの Ingress サブドメインに、公開されたアプリの Ingress リソース・パスを付加したものです (例: mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp)。

2. DNS システム・サービスは、経路サブドメインを、MZLB から正常と報告された Ingress コントローラー・サービスの浮動パブリック IP アドレスに解決します。 MZLB は、クラスター内の各ゾーンで Ingress コントローラーを公開するサービスのポータブル・パブリック IP アドレスを継続的に検査します。 要求は、ラウンドロビン・サイクルでさまざまなゾーンの Ingress コントローラー・サービスによって処理されます。

3. クライアントが Ingress コントローラーを公開しているサービスの IP アドレスに要求を送信します。

4. Ingress コントローラーは、Ingress コントローラーで実装されたルーティング・ルールの中に myapp パスがあるかどうかを検査します。 一致するルールが見つかると、要求は、Ingress コントローラーで定義したルールと Route リソースに従って、アプリがデプロイされているポッドにプロキシー処理されます。 パケットのソース IP アドレスが、Ingress コントローラー・ポッドが実行されるワーカー・ノードの IP アドレスに変更されます。 複数のアプリ・インスタンスがクラスターにデプロイされている場合、Ingress コントローラー・サービスは、すべてのゾーンのアプリ・ポッド間で要求を送信します。

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

パブリック・クラウド・サービス・エンドポイントがある VPC クラスター

パブリック・クラウド・サービス・エンドポイントを有効にしてマルチゾーン VPC クラスターを作成すると、デフォルトでは、パブリック Ingress コントローラーが作成されます。 次の図は、Ingress がインターネットから VPC 複数ゾーン・クラスター内のアプリへの通信をどのように誘導するかを示しています。

1. ユーザーがアプリの URL にアクセスしてアプリに要求を送信します。 この URL は、公開されたアプリのクラスターの Ingress サブドメインに、Ingress リソース・パスを付加したものです (例: mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp)。

2. DNS サービスは、経路サブドメインを、Ingress コントローラーに割り当てられた VPC ロード・バランサーのホスト名に解決します。 VPC クラスターの場合は、外部 IP アドレスが流動的であるため、VPC から割り当てられたホスト名が代わりに使用されます。

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

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

5. Ingress コントローラーは、Ingress コントローラーで実装されたルーティング・ルールの中に myapp パスがあるかどうかを検査します。 一致するルールが見つかると、要求は、Ingress コントローラーで定義したルールと Route リソースに従って、アプリがデプロイされているポッドにプロキシー処理されます。 パケットのソース IP アドレスが、Ingress コントローラー・ポッドが実行されるワーカー・ノードの IP アドレスに変更されます。 複数のアプリ・インスタンスがクラスターにデプロイされている場合、Ingress コントローラは、すべてのゾーンのアプリ・ポッド間で要求のロード・バランシングを行います。

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

プライベート・クラウド・サービス・エンドポイントしかない VPC クラスター

プライベート・クラウド・サービス・エンドポイントのみを使用して複数ゾーン VPC クラスターを作成すると、デフォルトでは、プライベート Ingress コントローラーが作成されます。 プライベートの Ingress コントローラーで公開されるアプリには、プライベートの VPC ネットワークに接続しているクライアントしかアクセスできません。 次の図は、Ingress がプライベート・ネットワークから VPC 複数ゾーン・クラスター内のアプリへの通信をどのように誘導するかを示しています。

1. プライベートの VPC ネットワークに接続しているクライアントが、アプリの URL を使用してアプリに要求を送信します。 この URL は、公開されたアプリのクラスターの Ingress サブドメインに、Ingress リソース・パスを付加したものです (例: mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp)。 例えば、仮想プライベート・クラウド 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 コントローラーは、Ingress コントローラーで実装されたルーティング・ルールの中に myapp パスがあるかどうかを検査します。 一致するルールが見つかると、要求は、Ingress コントローラーで定義したルールと Route リソースに従って、アプリがデプロイされているポッドにプロキシー処理されます。 パケットのソース IP アドレスが、Ingress コントローラー・ポッドが実行されるワーカー・ノードの IP アドレスに変更されます。 複数のアプリ・インスタンスがクラスターにデプロイされている場合、Ingress コントローラは、すべてのゾーンのアプリ・ポッド間で要求のロード・バランシングを行います。

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