Ingress を使ってアプリを公開する

Ingressコントローラーによって管理されるIngressリソースを作成することで、 Red Hat® OpenShift® on IBM Cloud® クラスター内の複数のアプリを外部から公開します。

前提条件

Ingress の使用を開始する前に、以下の前提条件を確認してください。

  • Ingress をセットアップするには、以下の IBM Cloud IAM 役割が必要です。
    • IBM Cloud Kubernetes Service におけるクラスタの管理者プラットフォームアクセスロール。
    • すべての IBM Cloud Kubernetes Service ネームスペース（ Red Hat OpenShift プロジェクト）における「 Manager 」サービスアクセスロール。
  • ゾーンで障害が発生すると、そのゾーンの Ingress コントローラーによって公開されているアプリへの要求で断続的な障害が発生する可能性があります。
  • 高可用性を確保するには、ゾーンごとにワーカー・ノードを 2 台以上配置することをお勧めします。
  • VPC クラスター：Ingress によってルーティングされるトラフィックリクエストを、ワーカーノードのノードポートに許可します。 詳細については、 「デフォルトでセキュアなクラスタVPCネットワークについて 」および「 VPCセキュリティグループの作成と管理 」を参照してください。
  • VPCマルチゾーンクラスター：CLIでクラスターを作成し、その後 ibmcloud oc zone add vpc-gen2 コマンドを使用してワーカープールにゾーンを手動で追加した場合は、 Ingressコントローラーを公開しているVPCロードバランサーを更新し、クラスター内のすべてのゾーンのサブネットを含めるようにする必要があります。
  • クラシック・クラスター: IBM Cloud インフラストラクチャー・アカウントの仮想ルーター機能 (VRF) を有効にする必要があります。 VRF を有効にするには、VRF の有効化を参照してください。 VRF が既に有効になっているかどうかを確認するには、ibmcloud account show コマンドを使用します。 VRF を有効にできない、または有効にしない場合は、VLAN スパンニングを有効にします。 VRF または VLAN のスパンニングを有効にすると、Ingress コントローラーは、アカウント内のさまざまなサブネットにパケットをルーティングできるようになります。

パブリッククラウドサービスのエンドポイントを使用して、クラスター内のアプリを公開する

定番のクラスター 仮想プライベートクラウド

クラスターがクラシック・インフラストラクチャー上で作成されている場合、またはVPCインフラストラクチャ上で作成され、作成時にパブリッククラウドサービスエンドポイントを有効にしている場合は、デフォルトのパブリックIngressコントローラーを使用して、クラスター内のアプリケーションを公開し、パブリックネットワークからのリクエストを受け取ることができます。

始める前に

ステップ 1: アプリをデプロイしてアプリ・サービスを作成する

まず、アプリをデプロイし、それらを公開するための Kubernetes サービスを作成します。

  1. アプリをクラスターにデプロイします。 構成ファイルの metadata セクションで、デプロイメントにラベルを追加しておく必要があります (例えば、app: code)。 このラベルは、アプリが実行されるすべてのポッドを識別して、ポッドが Ingress ロード・バランシングに含まれるようにするために必要です。

  2. 公開するアプリ・デプロイメントごとに、Kubernetes ClusterIP サービスを作成します。 アプリを Ingress ロード・バランシングに含めるには、Kubernetes サービスを介してアプリを公開する必要があります。

oc expose deploy <app_deployment_name> --name my-app-svc --port <app_port> -n <namespace>

ステップ 2: TLS の証明書と Kubernetes のシークレットを使用して、 TLS ターミネーションを設定する

TLS の証明書は、アプリが存在する各ネームスペースに「 Kubernetes 」のシークレットとして保存する必要があります。

ステップ 3: Ingress リソースを作成する

Ingress リソースでは、Ingress コントローラーがトラフィックをアプリ・サービスにルーティングするために使用するルーティング・ルールを定義します。

  1. IBM 提供のドメインまたはカスタム・ドメインを使用して着信ネットワーク・トラフィックを作成済みのサービスにルーティングするための Ingress リソース構成ファイルを定義します。

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myingressresource
spec:
  tls:
  - hosts:
    - <domain>
    secretName: <secret_name>
  rules:
  - host: <domain>
    http:
      paths:
      - path: /<app1_path>
        pathType: Prefix
        backend:
            service:
                name: test
                port:
                    number: 80
      - path: /<app2_path>
        backend:
            service:
                name: <app2_service>
                port:
                    number: 80
    tls
    TLS を使用する場合は、この TLS セクションをリソースに含めます。 <domain> をサブドメインに置き換えます。 Ingress の作成中に障害が発生しないようにするために、ホストに * を使用したり、ホスト・プロパティーを空のままにしたりしないでください。 <tls_secret_name> を、以前に作成した、カスタム・ドメインの TLS 証明書と鍵を保持するシークレット、または IBM 提供のサブドメイン用に自動的に生成された TLS シークレットに置き換えます。
    host
    <domain> を、IBM 提供の Ingress サブドメインまたはカスタム・ドメインに置き換えます。 クラスター内の複数のプロジェクトでアプリを公開する場合は、プロジェクトごとに 1 つの Ingress リソースが必要になります。 各リソースで同じサブドメインを使用することも、リソースごとに異なるサブドメインを使用することもできます。 例えば、ワイルドカード・ドメインを使用する場合、ドメインの先頭にワイルドカード・サブドメイン (subdomain1.custom_domain.net または subdomain1.mycluster-<hash>-0000.us-south.containers.appdomain.cloud など) を追加できます。 Ingress の作成中に障害が発生しないようにするために、ホストに * を使用したり、ホスト・プロパティーを空のままにしたりしないでください。
    path
    <app_path> を、アプリがリスニングしているパスに置き換えてください。 IBM 提供のドメインまたはカスタム・ドメインにパスが追加され、アプリへの固有の経路が作成されます。 この経路を Web ブラウザーに入力すると、ネットワーク・トラフィックが Ingress コントローラーにルーティングされます。 Ingress コントローラーは関連付けられたサービスを検索し、Ingress コントローラーはネットワーク・トラフィックをサービスに送信します。 そして、サービスが、アプリを実行するポッドにトラフィックを転送します。 多くのアプリは特定のパスで listen するのではなく、ルート・パスと特定のポートを使用します。 この場合、ルート・パスを / として定義します。アプリの個別のパスは指定しないでください。 http://domain/ の場合、/ をパスとして入力します。 http://domain/app1_path の場合、/app1_path をパスとして入力します。
    pathType
    URL パス・マッチング方式。 サポートされている値は、ImplementationSpecific、Exact、または Prefix です。 各パス種別に関する詳細情報や例については、 コミュニティの「 Kubernetes 」ドキュメントを参照してください。
    name
    <app1_service> および <app2_service> などを、アプリを公開するために作成したサービスの名前に置き換えます。 クラスターの別々のプロジェクトにあるサービスによってアプリを公開する場合は、同じプロジェクトにあるアプリ・サービスだけを組み込んでください。 公開するアプリを入れるプロジェクトごとに 1 つの Ingress リソースを作成する必要があります。
    port
    サービスが listen するポート。 アプリ用に Kubernetes サービスを作成したときに定義したものと同じポートを使用します。

  2. クラスターの Ingress リソースを作成します。 リソースで指定したアプリ・サービスと同じプロジェクトにリソースがデプロイされていることを確認します。

    oc apply -f myingressresource.yaml -n <project>

  3. Ingress リソースが正常に作成されたことを確認します。 イベントのメッセージにリソース設定のエラーが記載されている場合は、リソースファイル内の値を修正し、そのリソースに対してファイルを再適用してください。

    oc describe ingress myingressresource

Ingress リソースがアプリ・サービスと同じプロジェクト内に作成され、アプリが Ingress コントローラーに登録されます。

ステップ 4: インターネットからアプリにアクセスする

Web ブラウザーに、アクセスするアプリ・サービスの URL を入力します。

https://<domain>/<app1_path>

複数のアプリを公開した場合は、URL に追加するパスを変更して、それぞれのアプリにアクセスしてください。

https://<domain>/<app2_path>

ワイルドカード・ドメインを使用する場合は、それぞれのサブドメインを使用して各アプリにアクセスしてください。

http://<subdomain1>.<domain>/<app1_path>

http://<subdomain2>.<domain>/<app1_path>

Ingress を介してアプリに接続できませんか? Ingress のトラブルシューティングを試してください。

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

仮想プライベートクラウド

クラスターがVPCインフラストラクチャ上で作成され、作成時にプライベートクラウドサービスエンドポイントのみを有効にした場合、そのクラスターにはデフォルトでプライベートIngressコントローラーのみが設定されます。 アプリをパブリックに公開するには、まず、パブリック Ingress コントローラーを作成する必要があります。 その後、その Ingress コントローラーをサブドメインに登録する必要があります。オプションで独自の TLS 証明書をインポートします。

ステップ 1: アプリをデプロイしてアプリ・サービスを作成する

まず、アプリをデプロイし、それらを公開するための Kubernetes サービスを作成します。

  1. アプリをクラスターにデプロイします。 構成ファイルの metadata セクションで、デプロイメントにラベルを追加しておく必要があります (例えば、app: code)。 このラベルは、アプリが実行されるすべてのポッドを識別して、ポッドが Ingress ロード・バランシングに含まれるようにするために必要です。

  2. 公開するアプリ・デプロイメントごとに、Kubernetes ClusterIP サービスを作成します。 アプリを Ingress ロード・バランシングに含めるには、Kubernetes サービスを介してアプリを公開する必要があります。

oc expose deploy <app_deployment_name> --name my-app-svc --port <app_port> -n <namespace>

ステップ 2: TLS の証明書と Kubernetes のシークレットを使用して、 TLS ターミネーションを設定する

TLS の証明書は、アプリが存在する各ネームスペースに「 Kubernetes 」のシークレットとして保存する必要があります。

TLS Ingressのカスタムドメインに関する秘訣

外部プロバイダーで登録したドメインなど、ご自身で作成したドメインを使用する場合は、「 カスタムサブドメイン用の TLS シークレットの設定」を 参照してください。

TLS IBM で管理されるIngressドメインの秘訣

以下の手順に従って、 IBM が管理するIngressドメイン用の TLS シークレットを設定してください。

  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 に変更されます。 n+1 値は、このクラスターで次に連続して作成するサブドメインを示します。 後の手順でこのサブドメインを登録します。 ドメインを登録すると、そのドメイン用の TLS シークレットが自動的に生成されます。 シークレット名は、サブドメインを切り捨てた形式になります (mycluster-a1b2cdef345678g9hi012j3kl4567890-0003 など)。

ステップ 3: パブリック Ingress コントローラーを作成して構成する

ドメインと TLS 証明書を準備できたら、パブリック Ingress コントローラーを作成し、そのコントローラーにドメインを構成する必要があります。

  1. パブリック Ingress コントローラーの構成ファイルを作成します。

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

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

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

  3. oc get コマンドを実行し、 router-public-ingress-controller サービスの EXTERNAL IP フィールドで VPC ホスト名を見つけます。 VPC クラスターでは、サービスの外部 IP アドレスは非静的であるため、VPC で割り当てられるホスト名が代わりに使用されます。

    oc get svc router-public-ingress-controller -n openshift-ingress

    出力例

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

  4. サービスの VPC ホスト名を、事前に選択したドメインに登録します。

    • カスタム・ドメイン: DNS プロバイダーと連携して、router-public-ingress-controller サービスの VPC ホスト名を、カスタム・ドメインにマップする CNAME として追加します。
    • IBM 提供ドメイン: router-public-ingress-controller サービスの VPC ホスト名を DNS に登録します。 以下のコマンドを実行すると、public-ingress-controller.yaml ファイルに指定したサブドメインが自動的に生成され、router-public-ingress-controller サービスに登録されます。 このドメイン用の TLS シークレットが、アプリの実行先として指定したプロジェクトに自動的に生成されます。 シークレット名は、サブドメインを切り捨てた形式になります (mycluster-a1b2cdef345678g9hi012j3kl4567890-0003 など)。
        ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <VPC_hostname> --secret-namespace <project>
    ```

ステップ 4: Ingress リソースを作成する

Ingress リソースでは、Ingress コントローラーがトラフィックをアプリ・サービスにルーティングするために使用するルーティング・ルールを定義します。

  1. IBM 提供のドメインまたはカスタム・ドメインを使用して着信ネットワーク・トラフィックを作成済みのサービスにルーティングするための Ingress リソース構成ファイルを定義します。

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myingressresource
spec:
  tls:
  - hosts:
    - <subdomain>
    secretName: <custom_secret_name>
  rules:
  - host: <subdomain>
    http:
      paths:
      - path: /<app1_path>
        pathType: Prefix
        backend:
            service:
              name: <app1_service>
              port:
                number: 80
      - path: /<app2_path>
        backend:
            service:
              name: <app2_service>
              port:
                number: 80
    tls
    TLS を使用する場合は、この TLS セクションをリソースに含めます。
    `<domain>` をサブドメインに置き換えます。 Ingress の作成中に障害が発生しないようにするために、ホストに &ast; を使用したり、ホスト・プロパティーを空のままにしたりしないでください。

    `<tls_secret_name>` は、以前に作成したシークレットに置き換えます。このシークレットには、カスタム・ドメインの TLS 証明書と鍵、または IBM 提供のサブドメイン用に自動的に生成された TLS シークレットが保持されます。
    host
    <domain> をサブドメインに置き換えます。 クラスター内の複数のプロジェクトでアプリを公開する場合は、プロジェクトごとに 1 つの Ingress リソースが必要になります。 各リソースで同じサブドメインを使用することも、リソースごとに異なるサブドメインを使用することもできます。 例えば、ワイルドカード・ドメインを使用する場合は、ドメインの先頭にワイルドカード・サブドメインを追加できます (subdomain1.custom_domain.net など)。 Ingress の作成中に障害が発生しないようにするために、ホストに * を使用したり、ホスト・プロパティーを空のままにしたりしないでください。
    path
    <app_path> を、アプリがリスニングしているパスに置き換えてください。 IBM 提供のドメインまたはカスタム・ドメインにパスが追加され、アプリへの固有の経路が作成されます。 この経路を Web ブラウザーに入力すると、ネットワーク・トラフィックが Ingress コントローラーにルーティングされます。 Ingress コントローラーは、関連付けられたサービスを検索し、そのサービスにネットワーク・トラフィックを送信します。 そして、サービスが、アプリを実行するポッドにトラフィックを転送します。 多くのアプリは特定のパスで listen するのではなく、ルート・パスと特定のポートを使用します。 この場合、ルート・パスを / として定義します。アプリの個別のパスは指定しないでください。 たとえば、http://domain/ を使うには、パスとして / と入力します。 http://domain/app1_path の場合、/app1_path をパスとして入力します。
    pathType
    URL パス・マッチング方式。 サポートされている値は、ImplementationSpecific、Exact、または Prefix です。 各パス種別に関する詳細情報や例については、 コミュニティの「 Kubernetes 」ドキュメントを参照してください。
    name
    <app1_service> および <app2_service> などを、アプリを公開するために作成したサービスの名前に置き換えます。 クラスターの別々のプロジェクトにあるサービスによってアプリを公開する場合は、同じプロジェクトにあるアプリ・サービスだけを組み込んでください。 公開するアプリを入れるプロジェクトごとに 1 つの Ingress リソースを作成する必要があります。
    port
    サービスが listen するポート。 アプリ用に Kubernetes サービスを作成したときに定義したものと同じポートを使用します。

  2. クラスターの Ingress リソースを作成します。 リソースで指定したアプリ・サービスと同じプロジェクトにリソースがデプロイされていることを確認します。

    oc apply -f myingressresource.yaml -n <project>

  3. Ingress リソースが正常に作成されたことを確認します。 イベントのメッセージにリソース設定のエラーが記載されている場合は、リソースファイル内の値を修正し、そのリソースに対してファイルを再適用してください。

    oc describe ingress myingressresource

Ingress リソースがアプリ・サービスと同じプロジェクト内に作成され、アプリが Ingress コントローラーに登録されます。

ステップ 5: インターネットからアプリにアクセスする

Web ブラウザーに、アクセスするアプリ・サービスの URL を入力します。

https://<domain>/<app1_path>

複数のアプリを公開した場合は、URL に追加するパスを変更して、それぞれのアプリにアクセスしてください。

https://<domain>/<app2_path>

ワイルドカード・ドメインを使用する場合は、それぞれのサブドメインを使用して各アプリにアクセスしてください。

http://<subdomain1>.<domain>/<app1_path>

http://<subdomain2>.<domain>/<app1_path>

Ingress を介してアプリに接続できませんか? Ingress のトラブルシューティングを試してください。

クラスター外のアプリをパブリックに公開する

クラスター外にあるアプリをパブリック Ingress のロード・バランシングに組み込んでパブリックに公開します。 IBM 提供のドメインまたはカスタム・ドメインに着信したパブリック要求が自動的にその外部アプリに転送されます。

作業を開始する前に、クラスタのロードバランシングに組み込みたい外部アプリが、パブリックIPアドレスを介してアクセス可能であることを確認してください。

クラスター外のアプリを一般に公開するには、以下の手順に従ってください。

  1. Ingressコントローラーが公開するアプリ用の Kubernetes サービス設定ファイルを定義します。 このサービスが、後の手順で作成する外部エンドポイントに着信要求を転送します。

    apiVersion: v1
kind: Service
metadata:
  name: myexternalservice
spec:
  ports:
   - protocol: TCP
     port: <app_port>

  2. クラスター内にサービスを作成します。

    oc apply -f myexternalservice.yaml

  3. 外部エンドポイントの構成ファイルを定義します。 外部アプリにアクセスするために使用可能な、すべてのパブリック IP アドレスとポートを含めます。 なお、エンドポイントの名前は、前の手順で作成したサービスの名前と同じである必要があります。たとえば、 myexternalservice などです。

    kind: Endpoints
apiVersion: v1
metadata:
  name: myexternalservice
subsets:
  - addresses:
      - ip: <external_IP1>
      - ip: <external_IP2>
    ports:
      - port: <external_port>
    name
    <myexternalendpoint> を、先ほど作成した Kubernetes service の名前に置き換えます。
    ip
    <external_IP> を、外部アプリに接続するためのパブリック IP アドレスに置き換えます。
    port
    <external_port> を、外部アプリが listen するポートに置き換えます。

  4. クラスター内にエンドポイントを作成します。

    oc apply -f myexternalendpoint.yaml

  5. プライベート・クラウド・サービス・エンドポイントのみを使用して VPC クラスターでアプリをパブリックに公開する 、または パブリック・クラウド・サービス・エンドポイントを使用してクラスターでアプリをパブリックに公開する の 2 番目のステップに進みます。