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コントローラのみで作成されます。 アプリをプライベートに公開するには、まず、プライベート 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 シークレット

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

IBM管理対象ドメインの 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: private-ingress-controller
  namespace: openshift-ingress-operator
spec:
  #defaultCertificate: If you are using a custom domain, specify the domain certificate
    #name: custom-certs-default
  replicas: 2
  domain: <domain>
  endpointPublishingStrategy:
    loadBalancer:
      scope: Internal
    type: LoadBalancerService
  2. クラスターの openshift-ingress-operator プロジェクトに IngressController リソースを作成します。 IngressController,を作成すると、前のステップで設定したIngressControllerの設定に基づいて、openshift-ingress プロジェクトにプライベートIngressコントローラが自動的に作成され、デプロイされます。 さらに、IPアドレス（クラシッククラスタ）またはVPCホスト名（VPCクラスタ）でIngressコントローラを公開するIngressコントローラサービスが作成されます。 
    oc create -f private-ingress-controller.yaml -n openshift-ingress-operator
  3. oc get コマンドを実行し、 router-private-ingress-controller サービスの EXTERNAL IP フィールドで IP アドレスまたは VPC ホスト名を見つけます。
    oc get svc router-private-ingress-controller -n openshift-ingress
    クラシック・クラスターの出力例。 
    NAME                                  TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
router-private-ingress-controller     LoadBalancer   172.21.57.132    10.XX.XX.XX    80/TCP,443/TCP,1940/TCP      3m
    VPC クラスターの出力例:
    NAME                                  TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
router-private-ingress-controller     LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
  4. サービスの外部 IP アドレスまたは VPC ホスト名を、事前に選択したドメインに登録します。
    • カスタム・ドメイン: DNS プロバイダーと連携し、router-private-ingress-controller サービスの外部 IP アドレスを、カスタム・ドメインにマップする A レコードとして追加するか (クラシック・クラスターの場合)、VPC ホスト名を、カスタム・ドメインにマップする CNAME として追加します (VPC クラスターの場合) 。
    • IBM 提供ドメイン: router-private-ingress-controller サービスの VPC ホスト名を DNS に登録します。 以下のコマンドを実行すると、private-ingress-controller.yaml ファイルに指定したサブドメインが自動的に生成され、router-private-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>
        backend:
            service:
                name: <app1_service>
                port:
                    number: 80
      - path: /<app2_path>
        backend:
            serivce:
              name: <app2_service>
              port:
                number: 80
    tls
    TLS を使用する場合は、この TLS セクションをリソースに含めます。 <domain> をサブドメインに置き換えます。 Ingress の作成中に障害が発生しないようにするために、ホストに * を使用したり、ホスト・プロパティーを空のままにしたりしないでください。
    `<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 をパスとして入力します。
    serviceName
    <app1_service> および <app2_service> などを、アプリを公開するために作成したサービスの名前に置き換えます。 クラスターの別々のプロジェクトにあるサービスによってアプリを公開する場合は、同じプロジェクトにあるアプリ・サービスだけを組み込んでください。 Ingressリソースは、公開したいアプリを含むプロジェクトごとに1つずつ作成する必要があります。
    servicePort
    サービスが listen するポート。 アプリ用に Kubernetes サービスを作成したときに定義したものと同じポートを使用します。

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

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

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

    oc describe ingress myingressresource

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

ステップ 5: プライベート・ネットワークからアプリにアクセスする

  1. クラシック・クラスター: アプリにアクセスする前に、DNS サービスにアクセスできることを確認します。 デフォルトの外部DNSプロバイダを使用するには、パブリックアクセスが可能なエッジノードを構成し、Virtual Router Applianceを構成する必要があります。

  2. プライベート・ネットワーク内で、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コントローラを使用して、クラスタ内のアプリをプライベートネットワークからのリクエストに公開できます。

ステップ 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:
    - <custom_domain>
    secretName: <custom_secret_name>
  rules:
  - host: <domain>
    http:
      paths:
      - path: /<app1_path>
        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> を、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 コントローラーは、関連付けられたサービスを検索し、そのサービスにネットワーク・トラフィックを送信します。 そして、サービスが、アプリを実行するポッドにトラフィックを転送します。 多くのアプリは特定のパスで listen するのではなく、ルート・パスと特定のポートを使用します。 この場合、ルート・パスを / として定義します。アプリの個別のパスは指定しないでください。
    例えば、 http://domain/ を使用するには、パスとして / と入力します。 http://domain/app1_path の場合、/app1_path をパスとして入力します。
    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 のトラブルシューティングを試してください。