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

次の図は、 OpenShift ウェブ・コンソールに接続するためのパブ リック・サービス・エンドポイントとプライベート・サービス・エンドポイントの両方を持つ VPC クラスターの接続フローを示しています。 ウェブ・ブラウザからクラスタ・コンポーネントへの接続はすべてパブリック・ネットワーク経由で行われることに注意してください。 この図と以下の説明を見直して、どのようなトラブルシューティング手順が必要かをよりよく理解してください。

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

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

1. ウェブブラウザがパブリックネットワークにアクセスできるようにして、クラスタ・アピサーバ、 OpenShift コンソール・ロードバランサ、IAM（ iam.cloud.ibm.com と login.ibm.com の両方を使用）に接続できるようにしてください
2. このクラスタまたはロードバランサのセキュリティグループ、ACL、またはCBR（Context-Base Restriction）ルールを変更した場合、このウェブブラウザからこれらのリソースへのトラフィックが許可されていることを確認してください

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.<REGION>.containers.cloud.ibm.com:<YYYYY>`.
   
   
   

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

   1. kubectl get --raw /.well-known/oauth-authorization-server | grep issuer コマンドを実行します。 このコマンドは異なる URL を返すかもしれないので、 ibmcloud oc cluster get -c CLUSTER_ID は使わないこと。

       kubectl get --raw /.well-known/oauth-authorization-server | grep issuer
       ```
   2. URL は以下の形式でなければならない： `https://c<XXX>-e.<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. クラスタ上のコンテキストベースの制限（CBR）ルールによって、クライアントがクラスタAPIサーバに接続できないかどうかを確認します。 パブリックCBRルールに、すべてのIPとサブネットを許可するネットワークゾーンを一時的に追加することで、これをテストできる。 この一時的な変更で問題が解決した場合は、トラフィックを許可するルールに必要な変更を加える。
   
   

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. ロードバランサーに適用されているセキュリティグループ、ACL、カスタムVPCルートを変更した場合、適用した変更やルールが接続を妨げていないか確認してください。 これらのコンポーネントを変更しておらず、デフォルト値を使用している場合は、このステップをスキップできます。
   
   

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. クラスタ上のコンテキストベースの制限（CBR）ルールによって、クライアントがクラスタ OAuth サーバに接続できないかどうかを確認します。 パブリックCBRルールに、すべてのIPとサブネットを許可するネットワークゾーンを一時的に追加することで、これをテストできる。 この一時的な変更で問題が解決した場合は、トラフィックを許可するルールに必要な変更を加える。
   
   

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 を開きます。 ケースの詳細には、関連するログファイル、エラーメッセージ、コマンド出力を必ず含めてください。