Satellite クラスターのアプリの公開

パブリック・ネットワーク、ホストのプライベート・ネットワークに接続されているリソース、または Satellite のリソースからのトラフィック要求に対して、IBM Cloud クラスターで実行されるアプリを安全に公開します。

次のように、Satellite クラスターのアプリを公開する方法はいくつかあります。

  • MetalLB: オンプレミスの Satellite クラスターに適した LoadBalancer 実装。
  • Red Hat OpenShift 経路: パブリック・ネットワークまたはプライベート・ネットワークからの要求に対して、ホスト名を使用してアプリを素早く公開します。 Red Hat OpenShift Ingress コントローラーは、経路の DNS 登録とオプションの証明書を提供します。
  • サード・パーティーのロード・バランサーと Red Hat OpenShift 経路: ホスト名を使用してアプリを公開し、Ingress コントローラーの DNS レコードに登録されているホスト IP アドレスのヘルス・チェックを追加します。
  • NodePort: 30000 から 32767 までの範囲の NodePort を使用して、非 HTTP(S) アプリ (UDP アプリや TCP アプリなど) を公開します。
  • Red Hat OpenShift 経路と Satellite Link エンドポイント: プライベート経路を使用してアプリを公開し、その経路のために location タイプの Link エンドポイントを作成します。 IBM Cloud プライベート・ネットワークに接続されているリソースのみが、アプリにアクセスできます。

MetalLB のセットアップ

MetalLB は、ベアメタル Kubernetes クラスター用のロード・バランサー実装であり、標準ルーティング・プロトコルを使用します。 詳細については、ドキュメント Red Hat OpenShift の 「概要」 MetalLB および「 MetalLB 演算子」 を参照してください。

MetalLB,をインストールして設定するには、Red Hat OpenShiftドキュメントの「InstallingMetalLBOperator」の説明に従ってください。 始める前に、 LoadBalancer サービスの外部 IP 用に専用のサブネット (IPAddressPool) があることを確認してください。 IPAddressPool に含まれている IP アドレスが予約されていないこと、または他の目的で使用されていないことを確認してください。そうしないと、ロード・バランシング機能が失敗する可能性があります。

Red Hat OpenShift 経路を使用してアプリを公開する

経路を使用して、Red Hat OpenShift Ingress コントローラーの外部 IP アドレスでクラスター内のサービスを素早く公開します。

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

経路の使用を開始する前に、以下の考慮事項を確認してください。

ホスト・ネットワーク接続
クラスターのホストにパブリック・ネットワーク接続がある場合、クラスターはデフォルトでパブリック Ingress コントローラーを使用して作成されます。 この Ingress コントローラーを使用して、アプリのパブリック経路を作成できます。 クラスターのホストにプライベート・ネットワーク接続がある場合、クラスターはデフォルトでプライベート Ingress コントローラーを使用して作成されます。 この Ingress コントローラーを使用して、ホストのプライベート・ネットワーク内からのみアクセス可能なアプリのプライベート経路を作成できます。 プライベート・ネットワーク接続のみを持つクラスターでパブリック経路をセットアップするには、以下のステップを実行する前に、まず、プライベート Ingress コントローラーの前にパブリック・ネットワーク接続を持つ、独自のサード・パーティー・ロード・バランサーのセットアップをします。
ヘルス・チェック
DNS 登録管理は、クラスターの Ingress コントローラーに対してデフォルトで提供されます。 例えば、クラスターに割り当てられたホストをロケーションから削除し、それを別のホストに置き換えると、IBM は、Ingress コントローラーの DNS レコード内のホスト IP アドレスを自動的に更新します。 経路の DNS 登録は自動的に提供されますが、クラスター内の Ingress コントローラーの前にロード・バランサー・サービスはデプロイされないことに注意してください。 Ingress コントローラーの DNS レコードに登録されているホストの IP アドレスをヘルス・チェックするために、以下のステップを実行する前に、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.upi.containers.appdomain.cloud という形式で経路ホスト名が生成されます。 次のステップに進んでください。
    • カスタム・ドメイン: カスタム・ドメインを DNS プロバイダーと連携して作成します。 以前に Ingress コントローラーの前にサード・パーティーのロード・バランサーをセットアップした場合は、代わりに DNS プロバイダーと連携してロード・バランサーのカスタム・ドメインを作成してください。

  3. 外部 IP 列で、Ingress コントローラー・サービスの IP アドレスを取得します。

    oc get svc router-external-default -n openshift-ingress

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

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

  6. アプリが必要とする TLS 終端処理のタイプに基づいて、経路をセットアップします。 カスタムドメインをお持ちでない場合は、 --hostname オプションを含めないでください。そうすれば、ルートホスト名が自動的に生成されます。 ワイルドカード・サブドメインを登録した場合は、作成した経路ごとに固有のサブドメインを指定します。 例えば、この経路に --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` を実行して、経路をテストできます。
    {: tip}

* 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>]
    ```

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

    oc get routes

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

Red Hat OpenShift Ingress コントローラーの前にサード・パーティーのロード・バランサーをセットアップする

IngressコントローラーのDNSレコードに登録されているホストのIPアドレスのヘルスチェックを行うには、クラスターのワーカーノードとして割り当てられているホストのIPアドレスの前に、独自のサードパーティ製ロードバランサーを設定することができます。

例えば、クラスターに割り当てられたホストをロケーションから削除し、それを別のホストに置き換えると、IBM は、Ingress コントローラーの DNS レコード内のホスト IP アドレスを自動的に更新します。 ただし、クラウド・プロバイダーのインフラストラクチャー管理などによってホストの電源をオフにした場合、そのホストの IP アドレスは Ingress コントローラーの DNS レコードから削除されず、DNS レコードがそのホストの IP アドレスに解決されると呼び出しが失敗する可能性があります。 Ingress コントローラーの前にロード・バランサーをセットアップすることで、実動レベルのワークロードの高可用性を確保するためなど、ホスト IP アドレスが定期的にヘルス・チェックされるようにすることができます。

Ingress コントローラーの前にロード・バランサーを作成した後、Ingress コントローラーを使用してアプリの経路を作成でます。 アプリの経路に要求が送信されると、最初にその要求がロード・バランサーによって受信されてから、Ingress コントローラーに転送されます。その後、Ingress コントローラーはその要求をアプリに転送します。

  1. クラスターのデフォルト Ingress コントローラーの詳細をリストします。 出力の外部 IP 列で、クラスターの Ingress コントローラーに登録されているワーカー・ノードの IP アドレスを取得します。 出力のポート (S) 列で、パブリック・ロード・バランサーを作成するかプライベート・ロード・バランサーを作成するかに応じて、Ingress コントローラー・サービスがパブリック・ネットワーク・トラフィック用またはプライベート・ネットワーク・トラフィック用に現在公開しているノード・ポートを取得します。

    oc get svc router-external-default -n openshift-ingress

    以下の出力例では、ノード・ポート 30783 がパブリック・トラフィック (80) に対して公開されています。

    NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP                            PORT(S)                      AGE
router-external-default   LoadBalancer   172.21.84.172   169.xx.xxx.xxx, 169.xx.xxx.xxx         80:30783/TCP,443:30413/TCP   24h

  2. これらの IP アドレスとノード・ポートを使用して、ホストのプライベート・ネットワークに接続されたレイヤー 4 のロード・バランサーを作成します。 例えば、ホストのクラウド・プロバイダーからロード・バランサーをデプロイしたり、F5 ロード・バランサーをオンプレミスのネットワークにデプロイしたりできます。 パブリック経路を作成するには、ロード・バランサーがパブリック・ネットワーク接続を備え、前の手順で確認したパブリック・トラフィック用のポートに TCP および UDP のトラフィックを転送できる必要があります。 プライベート経路を作成するには、ロード・バランサーが、前の手順で確認したプライベート・トラフィック用のポートに TCP および UDP のトラフィックを転送できる必要があります。

  3. クラスターのホスト名を取得します。 <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud という形式のこのサブドメインは、クラスターの Ingress コントローラーに登録されます。

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

  4. クラスターのサブドメインにロード・バランサーのパブリック IP アドレスを追加します。 追加するすべてのパブリック IP アドレスについて、このコマンドを繰り返します。

    ibmcloud oc nlb-dns add --ip <public_IP> --cluster <cluster_name_or_ID> --nlb-host <hostname>

  5. クラスターのサブドメインからワーカー・ノードの IP アドレスを削除します。 先ほど取得したすべての IP アドレスについて、このコマンドを繰り返します。

    ibmcloud oc nlb-dns rm classic --ip <private_IP> --cluster <cluster_name_or_ID> --nlb-host <hostname>

  6. クラスターのサブドメインにロード・バランサーのパブリック IP アドレスが登録されたことを確認します。

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

  7. Red Hat OpenShift 経路を使用してアプリを公開するの手順を進めて、アプリの経路を作成します。

外部ロードバランサーやVIPを、デフォルトの登録設定ではなくサブドメインに登録するように設定する場合、そのロードバランサーは クラスターホストへのインバウンドアクセスが必要となり、クラスターホストはロードバランサーへのアウトバウンドアクセスが必要となります。

NodePort を使用してアプリを公開する

TCP アプリや UDP アプリを公開する必要がある場合などの、Red Hat OpenShift Ingress コントローラーを使用してアプリを公開できない場合は、アプリの NodePort を作成できます。

  1. アプリの NodePort を作成します。 30000 から 32767 までの範囲の NodePort と、内部クラスター IP アドレスがアプリに割り当てられます。

    oc expose deployment <deployment_name> --type=NodePort --name=<nodeport_svc_name>

  2. アプリに割り当てられた NodePort を取得します。

    oc describe svc <nodeport_svc_name>

  3. クラスターのホスト名を <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud の形式で取得します。

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

  4. クラスターのサブドメインと NodePort を <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud:<nodeport> という形式で使用して、アプリにアクセスします。 ホストにプライベート・ネットワーク接続しかない場合は、VPN アクセスなどを使用して、ホストのプライベート・ネットワークに接続しておく必要があることに注意してください。

  5. オプション: NodePort に直接アクセスしない場合、または特定のポート (443 など) でアプリを公開する必要がある場合は、ホストのプライベート・ネットワークに接続され、NodePort にトラフィックを転送する、独自のサード・パーティーのレイヤー 4 ロード・バランサーをセットアップできます。 例えば、ホストのクラウド・プロバイダーからロード・バランサーをデプロイしたり、F5 ロード・バランサーをオンプレミスのネットワークにデプロイしたりできます。 ロードバランサーは、ポート 30000 - 32767 に対する TCP および UDP のトラフィックを転送できる必要があります。

経路および Link エンドポイントを使用して IBM Cloud からのトラフィックに対してアプリを公開する

プライベート・ネットワークを介して Satellite クラスター内のアプリに IBM Cloud 内のリソースからアクセスする場合は、プライベート Ingress コントローラーを使用してアプリのプライベート経路を作成できます。 その後、その経路に対して、location タイプの Link エンドポイントを作成できます。これには、IBM Cloud プライベート・ネットワークの内部からのみアクセスできます。

  1. Red Hat OpenShift 経路を使用してアプリを公開するの手順に従って、アプリのプライベート経路を作成します。 この経路には、ホストのプライベート・ネットワークの内部からのみアクセスできます。

  2. ロケーション内のリソースに接続するための location エンドポイントの作成の手順に従って、アプリのプライベート経路に対する Satellite Link エンドポイントを作成します。

  3. オプション: エンドポイントへのアクセスを IBM Cloud の特定のリソースにのみ許可するには、エンドポイントのソース・リストにそのリソースを追加します。