プライベートVPCクラスタ： OpenShift コンソールに接続できないのはなぜですか？

プライベートサービスのエンドポイントのみを持つクラスタ上で OpenShift コンソールへの接続に関する問題をトラブルシューティングします。

このトラブルシューティングガイドの情報は、プライベートサービスエンドポイントのみを持つVPCクラスタに関するものです。

1. クラスタ接続の流れを理解する

次の図は、プライベートサービスエンドポイントを持つVPCクラスターが OpenShift ウェブコンソールに接続する際の接続の流れを示しています。 この図は、クラスタがデフォルトの OAuth 設定になっていることを前提としています。 この図と以下の説明をよく読み、どのようなトラブルシューティングが必要になるかを理解してください。

OpenShift
OpenShift プライベートサービスエンドポイントを持つVPCクラスターのウェブコンソール接続の流れ プライベートサービスエンドポイントを持つVPCクラスターのウェブコンソール接続の流れ。

  1. ウェブブラウザは、VPNを経由してクラスタマスターAPIサーバーに接続します。 署名済みの証明書が交換され、リダイレクトによりウェブブラウザが OpenShift コンソールロードバランサーに接続するように指示されます。
  2. (a) ウェブブラウザがVPN経由で OpenShift コンソールを公開する OpenShift コンソールロードバランサーに接続します。 (b) このリクエストは2つのopenshift-consoleポッドのうちの1つに送信されます。
  3. openshift-console pod はクラスタマスター OAuth サーバーポートに接続し、接続が認証済みかどうかを確認します。 リクエストがすでに認証されている場合、 OpenShift ウェブコンソールへの接続が完了し、ウェブコンソールにアクセスできるようになります。 リクエストが認証されていない場合、ユーザはクラスタマスタ上のクラスタ OAuth サービスにリダイレクトされます。
  4. ウェブ・ブラウザはVPNを通じてクラスタの OAuth サーバー・ポートに接続し、クライアントをIAMにリダイレクトする。
  5. ウェブブラウザは、公開ネットワークを介してIAMに接続します。 ユーザーはパスワードを入力し、必要に応じて 2FA の認証を行います。 このステップが成功すると、ユーザーはクラスタの OAuth ・サーバーにリダイレクトされます。
  6. ウェブ・ブラウザはVPNを通じてクラスタの OAuth サーバー・ポートに再び接続する。 接続は OpenShift コンソールのロードバランサーにリダイレクトされる。
  7. ウェブブラウザは、 OpenShift コンソールロードバランサーにVPN経由で接続し、 OpenShift コンソールを公開します。 このリクエストは2つのopenshift-consoleポッドのうちの1つに送信され、再度クラスタマスター OAuth サーバーポートに接続し、接続が認証済みかどうかを確認します。 ユーザーがパスワードを入力し、 2FA 認証を受けた場合、認証が有効化され、 OpenShift コンソールのメインウェブページに接続されます。

2. VPCとクラスタ構成を確認する

VPCとクラスタが正しく構成されていることを確認してください。 誤った設定により、 OpenShift のウェブコンソールにアクセスできない場合があります。

  1. ウェブブラウザが、クラスタと同じVPC内にあるか、そのVPCにVPN接続しているクライアントシステム上で動作していることを確認してください。 OpenShift コンソールは、VPCのプライベートネットワークからのみアクセス可能なプライベートVPCロードバランサーによって公開されています。

  2. クライアントシステムがIAMのパブリックサービスエンドポイントにアクセスできることを確認してください。これらのエンドポイントは、 iam.cloud.ibm.com と login.ibm.com からアクセスできます。

  3. バージョンを実行しているクラスタの場合 4.13:

    • クラスタがデフォルトの 4.13 Oauth構成を使用している場合、またはクラスタでVPE Gateway for Oauthを使用するように設定している場合は、クライアントがVPCのプライベートDNSを使用しており、このDNSトラフィックがVPN経由でVPCにルーティングされていることを確認してください。 プライベートDNSは通常、 161.26.0.7 と 161.26.0.8 です。ただし、カスタムDNSリゾルバを使用している場合はこの限りではありません。 これは、 apiserver と Oauth 用のVPE Gatewayが、どのパブリックDNSにも存在しないため、VPCのプライベートDNSで検出できるようにするために必要です。

  4. サポートされているバージョン以外のバージョンを実行しているクラスタについては、 4.13:

    • デフォルトの Oauth クラスタ設定を使用している場合は、すべての 166.8.0.0/14 トラフィックが同じ VPN または IBM Cloud に接続する別の VPN を経由するように、VPN 構成にルートが存在することを確認してください。 これはクラスタのAPIサーバーと OAuth サーバー・ポートに接続するために必要です。

3. クラスタデータを収集する

トラブルシューティングに必要なクラスタ情報を収集するには、以下の手順に従います。 これらのコマンドで収集した出力は、後のステップで使用されます。

  1. クラスタAPIサーバー URL を見つけます。 後のコマンドでは、この URL は ${CLUSTER_APISERVER_URL} と呼ばれます。

    1. ibmcloud ks cluster get -c CLUSTER_ID コマンドを実行します。
        ibmcloud oc cluster get -c CLUSTER_ID
    ```
2. 出力の `Master` セクションで、 `URL` を見つけます。 URL は次の形式で入力してください： `https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<YYYYY>`。

  2. クラスタ OAuth URL を見つける。 後のコマンドでは、この URL は ${CLUSTER_OAUTH_URL} と呼ばれます。

    1. kubectl get --raw /.well-known/oauth-authorization-server | grep issuer コマンドを実行します。 ibmcloud oc cluster get -c CLUSTER_ID は使用しないでください。このコマンドは異なる URL を返す可能性があるためです。
        kubectl get --raw /.well-known/oauth-authorization-server | grep issuer
    ```
2. 出力結果の中から、以下のいずれかの形式の URL を見つけます。
    - VPEゲートウェイが OAuth: `https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>` に使用されていない場合。
    - VPEゲートウェイを OAuth: `https://<CLUSTERID>.vpe.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>` に使用する場合。

  3. Ingressサブドメインを見つけます。 後続のコマンドでは、このサブドメインは ${CONSOLE_LOAD_BALANCER} と表記されます。

    1. ibmcloud oc cluster get -c CLUSTER_ID コマンドを実行します。
        ibmcloud oc cluster get -c CLUSTER_ID
    ```
2. 出力で、次の形式に一致するサブドメインを見つけます： `<CLUSTER-NAME-PLUS-RANDOM-UNIQUE-STRING>.<REGION>.containers.appdomain.cloud`。 カスタムのIngressサブドメインを設定している場合は、そのフォーマットが代わりにカスタム設定に一致します。

4. 接続の確認とトラブルシューティング

以下の手順に従って、 接続フロー で説明されている接続を確認してください。 接続に問題がある場合は、その情報を使用して問題のトラブルシューティングを行ってください。

  1. Ingressが正常に動作しており、ルーターとコンソールポッドが正常に動作していることを確認します。

    1. コマンドを実行します。
        ibmcloud oc cluster get -c CLUSTERID
    ibmcloud oc ingress status-report get -c CLUSTERID
    ```
2. 出力にエラー状態が表示された場合は [、Ingressのトラブルシューティングのドキュメント](/docs/openshift?topic=openshift-ingress-status) を参照して問題を解決してください。

  2. OpenShift クラスタのオペレーターが正常に動作していることを確認してください。

    1. コマンドを実行します。
        oc get clusteroperators
    ```
2. 出力結果に、健全ではないオペレータや、現在のバージョンで実行されていないオペレータがある場合は [、 OpenShift クラスタバージョンのトラブルシューティングのドキュメント](/docs/openshift?topic=openshift-ts-cluster-version-downlevel) を参照して問題を解決してください。 または、表示される特定のエラーについて、 IBM と Red Hat のドキュメントを検索することもできます。
3. コンソールオペレータが特に健全でない場合は、 `openshift-console/console...` および `openshift-console-operator/console-operator...` ポッドのログをチェックして、セキュリティグループ、ACL、または DNS のカスタマイズが、ポッドが OAuth ポートまたは OpenShift コンソール URL のいずれかに接続するのを妨げていないかどうかを確認します。 セキュリティグループ、ACL、DNSが、接続を妨げるように設定されている可能性があります。

  3. クラスタマスターAPIサーバーへの接続が成功していることを確認します。

    1. コマンドを実行します。 前の手順 で見つけたクラスタ apiserver URL を指定します。
        curl -k -vvv ${CLUSTER_APISERVER_URL}/version
    ```
2. 接続に成功しない場合は、以下のチェックを行い、問題が見つかった場合は解決してください。
    1. `ibmcloud oc cluster get -c <CLUSTER-ID>` コマンドを実行して、クラスタマスターが正常に動作していることを確認します。 クラスタマスターの問題の解決方法については [、「マスターの健康状態の確認」](/docs/openshift?topic=openshift-debug_master) を参照してください。
    2. URL のホスト名部分がDNS経由で解決されることを確認してください。 `dig $(echo ${CLUSTER_APISERVER_URL} | cut -d/ -f3 | cut -d: -f1)` コマンドを使用し、クラスタAPIサーバー URL を指定します。
    3. VPN経由でクラスタAPIサーバー URL に接続するルートがあることを確認してください。
    4. クラスタ apiserver URL にクラスタ ID が含まれている場合（クラスタがクラスタ apiserver への接続に VPE ゲートウェイを使用していることを示す）、クラスタマスターの VPE ゲートウェイセキュリティグループが、お客様の VPN クライアントサブネットからのトラフィックを許可していることを確認してください。 [OAuth アクセスがVPEゲートウェイに設定されている場合の OpenShift コンソールへのアクセス](/docs/openshift?topic=openshift-console-apiserver-oauthvpe) 」の手順に従ってください。
    5. VPNに適用されているセキュリティグループ、ACL、またはカスタムVPCルートが、VPNとクラスタAPIサーバー間のトラフィックを妨げていないか確認してください。 これをテストするには、VPNセキュリティグループとACLを通じて一時的にすべてのインバウンドおよびアウトバウンドのトラフィックを許可し、問題が解決するかどうかを確認します。 もしそうであれば、トラフィックを許可するために、セキュリティグループ、ACL、またはカスタムルートに必要な変更を加えてください。
    6. クラスタ上のコンテキストベースの制限（CBR）ルールによって、クライアントがクラスタAPIサーバに接続できないかどうかを確認します。 これをテストするには、一時的にすべてのIPおよびサブネットを許可するネットワークゾーンをCBRルールに追加します。 この一時的な変更で問題が解決した場合は、トラフィックを許可するルールに必要な変更を加える。

  4. OpenShift コンソールを公開しているクラスタロードバランサーへの接続が成功していることを確認してください。

    1. コマンドを実行します。 前のステップ で見つけた Ingress サブドメインを指定します。
        curl -k -vvv https://console-openshift-console.${CONSOLE_LOAD_BALANCER}/
    ```
2. 接続に成功しない場合は、以下のチェックを行い、問題が見つかった場合は解決してください。
    1. サブドメインのホスト名部分がDNS経由で解決されることを確認してください。 `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}`コマンドを使用します。
    2. VPNからこのロードバランサのサブドメインへの経路があることを確認してください。 ロードバランサーが使用するすべての IP またはサブネットがルートに含まれていることを確認してください。 `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}` コマンドの出力には、現在のロードバランサーのIPアドレスとサブネットが含まれますが、ロードバランサーのスケールアップまたはスケールダウンにより、これらが変更される可能性があることに注意してください。
    3. ロードバランサーに適用されているセキュリティグループ、ACL、またはカスタムVPCルートを変更した場合は、適用した変更またはルールが接続を妨げていないか確認してください。 これらのコンポーネントを一切変更しておらず、デフォルト値を使用している場合は、この手順をスキップできます。
    4. VPNに適用されているセキュリティグループ、ACL、またはカスタムVPCルートが、VPNとロードバランサー間のトラフィックを妨げていないか確認してください。 これをテストするには、VPNセキュリティグループとACLを通じて一時的にすべてのインバウンドおよびアウトバウンドのトラフィックを許可し、問題が解決するかどうかを確認します。 もしそうであれば、トラフィックを許可するために、セキュリティグループ、ACL、またはカスタムルートに必要な変更を加えてください。

  5. クラスタ OAuth サーバへの接続が成功したことを確認します。

    1. コマンドを実行します。 前のステップで 見つけたクラスタ OAuth URL を指定します。
        curl -k -vvv ${CLUSTER_OAUTH_URL}/healthz
    ```
2. 接続に成功しない場合は、以下のチェックを行い、問題が見つかった場合は解決してください。
    1. `ibmcloud oc cluster get -c <CLUSTER-ID>` コマンドを実行して、クラスタマスターが正常に動作していることを確認します。 クラスタマスターの問題の解決方法については [、「マスターの健康状態の確認」](/docs/openshift?topic=openshift-debug_master) を参照してください。
    2. クラスタ OAuth URL のホスト名部分がDNSで解決されていることを確認します。 `dig $(echo ${CLUSTER_OAUTH_URL} | cut -d/ -f3 | cut -d: -f1)` を使用し、クラスタ OAuth URL を指定する。
    3. クラスタ・マスターへのVPN経由のルートがあることを確認する OAuth URL.
    4. VPNに適用されているセキュリティグループ、ACL、またはカスタムVPCルートが、VPNとクラスタ OAuth サーバ間のトラフィックを妨げていないか確認してください。 これをテストするには、VPNセキュリティグループとACLを通じて一時的にすべてのインバウンドおよびアウトバウンドのトラフィックを許可し、問題が解決するかどうかを確認します。 もしそうであれば、トラフィックを許可するために、セキュリティグループ、ACL、またはカスタムルートに必要な変更を加えてください。
    5. クラスタ上のコンテキストベースの制限（CBR）ルールによって、クライアントがクラスタ OAuth サーバに接続できないかどうかを確認します。 これをテストするには、一時的にすべてのIPおよびサブネットを許可するネットワークゾーンをCBRルールに追加します。 この一時的な変更で問題が解決した場合は、トラフィックを許可するルールに必要な変更を加える。

  6. IAMへの接続が成功していることを確認します。

    1. コマンドを実行します。
        curl -vvv https://iam.cloud.ibm.com/healthz
    curl -vvv -o /dev/null -s https://login.ibm.com/
    ```
2. これらのコマンドのいずれかが失敗した場合は、クライアントシステムがこれらのURLに確実に接続できるかどうか、また、URLがクライアントまたは企業のファイアウォールによってブロックされていないかどうかを確認してください。 これらのURLにアクセスするには、インターネットへのアクセスが必要となりますのでご注意ください。

5. サポートに連絡

上記のすべてのステップを完了しても問題が解決しない場合は、サポートまでお問い合わせください。 サポート Case を開きます。 詳細情報には、関連するログファイル、エラーメッセージ、コマンド出力などを必ず含めるようにしてください。