IBM Cloud Docs
Ingressでアプリを公開

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プロジェクト）すべてで、マネージャサービスのアクセスロールを使用します。
  • ゾーンで障害が発生すると、そのゾーンの Ingress コントローラーによって公開されているアプリへの要求で断続的な障害が発生する可能性があります。
  • 高可用性を確保するには、ゾーンごとにワーカー・ノードを 2 台以上配置することをお勧めします。

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

クラシック・クラスター 仮想プライベート・クラウド

クラスタがクラシック・インフラストラクチャ上に作成されている場合、またはクラスタが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ドキュメントを/span>のを参照してください。
    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 クラスターでアプリをパブリックに公開する

Virtual Private Cloud

クラスタが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 シークレットとして保管する必要があります。

カスタム Ingress ドメインの TLS シークレット

自分で作成したドメイン (外部プロバイダーに登録されているドメインなど) を使用するには、 カスタム・サブドメインの TLS シークレットのセットアップ を参照してください。

IBM管理対象 Ingress ドメインの TLS シークレット

以下の手順に従って、 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ドキュメントを/span>のを参照してください。
    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 アドレスとポートを含めます。 Note that the name of the endpoint must be the same as the name of the service that you created in the previous step, for example, 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 番目のステップに進みます。