アプリの公開方式について

アプリを外部トラフィックに対して安全に公開するには、以下のサービスから選択できます。

Red Hat OpenShift Ingress コントローラー

Red Hat OpenShift のIngressコントローラーを使用してルーティングを設定し、クラスター内の複数のアプリを公開します。 Ingress コントローラーは、保護された固有のパブリック・エントリー・ポイントまたはプライベート・エントリー・エンドポイントとして Ingress サブドメインを使用して、着信要求をルーティングします。 1 つのサブドメインを使用してクラスター内の複数のアプリをサービスとして公開できます。 Ingress コントローラー・ソリューションは、3 つのコンポーネントを使用します。

• クラスター内の Ingress コントローラーを管理する Ingress オペレーター。
• Ingress コントローラーは HAProxy ベースの Kubernetes サービスで、クラスター内のアプリに関するルーティング・ルールを実装することによって、そのアプリに対するすべての着信トラフィックを管理します。 このコントローラーは、Ingress オペレーターによって管理されます。 Ingress コントローラーは、着信 HTTP または HTTPS サービス要求を listen し、Ingress リソースで定義され、Ingress コントローラーによって実装されたルールに従ってのみ、そのアプリのポッドに要求を転送します。
• ルート・リソースは、アプリの着信要求をルーティングしてロード・バランシングする方法に関する規則を定義します。

ルートは、<service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud という形式のホスト名としてサービスを公開します。 Ingress コントローラーはデフォルトでクラスターにデプロイされます。これにより、外部クライアントがルートを使用できるようになります。 Ingress コントローラーは、サービス・セレクターを使用して、サービスと、サービスをバックアップするエンドポイントを検出します。 1 つのルートを介して複数のサービスにトラフィックを送信するようにサービス・セレクターを構成できます。 また、Ingress コントローラーによってホスト名に割り当てられた TLS 証明書を使用して、保護されていないルートまたは保護されたルートを作成することもできます。 Ingress コントローラーは HTTP プロトコルと HTTPS プロトコルのみをサポートすることに注意してください。

NodePort

NodePort サービスを使用してアプリを公開する場合は、サービスに 30000 から 32767 までの範囲の NodePort と内部クラスター IP アドレスが割り当てられます。 クラスターの外部からサービスにアクセスするには、ワーカー・ノードのパブリック IP アドレスまたはプライベート IP アドレスと NodePort (形式 <IP_address>:<nodeport>) を使用します。 ただし、ワーカー・ノードのパブリックおよびプライベートの IP アドレスは不変ではありません。 ワーカー・ノードが削除されたり再作成されたりすると、新しいパブリック IP アドレスと新しいプライベート IP アドレスがワーカー・ノードに割り当てられます。 NodePort は、パブリックまたはプライベートのアクセスをテストしたり、短時間だけアクセスできるようにしたりする場合に適しています。

LoadBalancer

LoadBalancer サービス・タイプの実装は、クラスターのインフラストラクチャー・プロバイダーによって異なります。

• クラシック・クラスター: ネットワーク・ロード・バランサー (NLB)。 どの標準クラスターにも 4 つのポータブル・パブリック IP アドレスと 4 つのポータブル・プライベート IP アドレスがプロビジョンされます。そのアドレスを使用して、アプリ用のレイヤー 4 の TCP/UDP ネットワーク・ロード・バランサー (NLB) を作成できます。 アプリで必要なすべてのポートを公開することによって NLB をカスタマイズすることも可能です。 NLB に割り当てられたポータブル・パブリック IP アドレスとポータブル・プライベート IP アドレスは永続的なアドレスであり、クラスター内でワーカー・ノードが再作成されても変更されません。 パブリック NLB を作成する場合は、パブリック NLB の IP アドレスを DNS エントリーに登録するアプリのサブドメインを作成できます。 また、各サブドメインの NLB IP に対するヘルス・チェック・モニターも有効にできます。
• VPC クラスター: VPC ロード・バランサー。 クラスターでアプリ用に Kubernetes LoadBalancer サービスを作成すると、レイヤー 7 の VPC ロード・バランサーが VPC のクラスター外部に自動的に作成されます。 この VPC ロード・バランサーはマルチゾーン対応であり、ワーカー・ノードで自動的に開かれるプライベート NodePort を介してアプリに対する要求を転送します。 デフォルトで、このロード・バランサーにも、アプリへのアクセスに使用できるホスト名が作成されますが、アプリ用のサブドメインを自分で作成して DNS に登録することもできます。

Ingress

Ingress を使用すると、 Red Hat OpenShift Ingress コントローラーを介して外部トラフィックにアプリを公開できます。 Red Hat OpenShift コントローラー・マネージャーは、Ingress リソースをルート・リソースに変換し、Red Hat OpenShift Ingress コントローラーがそれらのルートを処理します。

ロード・バランシング・ソリューションの選択

Red Hat OpenShift クラスター内のアプリを公開するために必要なオプションの内容を理解したところで、ワークロードに最適なソリューションを選択してください。

以下の表では、各アプリ公開方式の機能を比較しています。

* SSL 終端処理は ibmcloud oc nlb-dns コマンドによって提供されます。 クラシック・クラスターでは、これらのコマンドはパブリック NLB でのみサポートされます。

パブリック外部ロード・バランシングの計画

クラスター内のアプリをインターネットに公開します。

クラシック・クラスターでは、ワーカー・ノードがパブリック VLAN に接続されます。 パブリック VLAN により、各ワーカー・ノードに割り当てられるパブリック IP アドレスが決まり、ワーカー・ノードにパブリック・ネットワーク・インターフェースが提供されます。 パブリック IP アドレスおよびオプションでパブリック URL を使用してアプリを提供すると、パブリック・ネットワーク・サービスがそのパブリック・ネットワーク・インターフェースに接続します。

VPC クラスターでは、ワーカー・ノードはプライベート VPC サブネットにのみ接続されます。 ただし、パブリック・ネットワーク・サービスを作成すると、VPC ロード・バランサーが自動的に作成されます。 VPC ロード・バランサーは、アプリにパブリック URL を与えて、パブリック要求をアプリに転送できるようにします。 公開したアプリのパブリック URL を知っていれば、だれでもアプリに要求を送信できます。

アプリをパブリックに公開すると、アプリにセットアップされたパブリック・サービス IP アドレスまたは URL を知っているだれもがアプリに要求を送信できるようになります。 このため、公開するアプリの数は、できるだけ少なくしてください。 外部の Web クライアントまたはユーザーからのトラフィックを受け入れる準備ができたアプリだけをパブリックに公開してください。

ワーカー・ノードのパブリック・ネットワーク・インターフェースは、クラスターの作成時にすべてのワーカー・ノードに構成される事前定義済み Calico ネットワーク・ポリシー設定によって保護されます。 デフォルトでは、すべてのワーカー・ノードに対して、すべてのアウトバウンド・ネットワーク・トラフィックが許可されます。 数個のポートを除いて、インバウンド・ネットワーク・トラフィックがブロックされます。 開かれているポートは、IBM がネットワーク・トラフィックをモニターし、Kubernetes マスターのセキュリティー更新を自動的にインストールするためのもの、および、パブリック・ネットワーク・サービスへの接続を確立できるようにするためのものです。 ポリシーの変更方法を含め、これらのポリシーの詳細については、ネットワーク・ポリシーを参照してください。

プライベート外部ロード・バランシングの計画

クラスター内のアプリをプライベート・ネットワークにのみ公開します。

IBM Cloud Kubernetes Service で Kubernetes クラスターにアプリをデプロイする場合は、そのクラスターと同じプライベート・ネットワーク上のユーザーとサービスのみがアプリを利用できるようにすることができます。 プライベート・ロード・バランシングは、アプリを一般的に公開することなく、クラスター外からの要求で使用できるようにする場合に理想的です。 プライベート・ロード・バランシングを使用して、アプリのアクセス、要求ルーティング、およびその他の構成をテストしてから、後でパブリック・ネットワーク・サービスを使用してアプリをパブリックに公開することもできます。

例えば、アプリ用にプライベート・ロード・バランサーを作成したとします。 このプライベート・ロード・バランサーには、以下がアクセスできます。

• 同じクラスター内のすべてのポッド。
• 同じ IBM Cloud アカウント内のクラスター内のポッド。
• IBM Cloud アカウントに含まれていないが、会社のファイアウォールの背後にある場合は、ロード・バランサー IP があるサブネットへの VPN 接続を介するすべてのシステム。
• 異なる IBM Cloud アカウントに含まれている場合は、ロード・バランサー IP があるサブネットへの VPN 接続を介するすべてのシステム。
• クラシック・クラスターの場合: VRF または VLAN スパンニングを有効にしていれば、同じ IBM Cloud アカウント内のプライベート VLAN に接続されているすべてのシステム。
• VPC クラスターの場合:
  • VPC サブネット間のトラフィックを許可していれば、同じ VPC 内のすべてのシステム。
  • VPC 間のトラフィックを許可していれば、クラスターが存在する VPC にアクセスできるすべてのシステム。