パブリックおよびプライベート・サービスのエンドポイントを持つVPCクラスタ: OpenShift コンソールに接続できません
パブリックとプライベートの両方のサービスエンドポイントを持つクラスタ上の OpenShift コンソールへの接続に関する問題のトラブルシューティング。
このトラブルシューティングガイドの情報は、パブリックとプライベートの両方のサービスエンドポイントを持つVPCクラスタに関係します。
1.クラスタ接続の流れを理解する
次の図は、 OpenShift ウェブ・コンソールに接続するためのパブ リック・サービス・エンドポイントとプライベート・サービス・エンドポイントの両方を持つ VPC クラスターの接続フローを示しています。 ウェブ・ブラウザからクラスタ・コンポーネントへの接続はすべてパブリック・ネットワーク経由で行われることに注意してください。 この図と以下の説明を見直して、どのようなトラブルシューティング手順が必要かをよりよく理解してください。
- ウェブブラウザはクラスタマスタAPIサーバに接続します。 署名された証明書が交換され、リダイレクトがウェブブラウザに OpenShift コンソールのパブリックロードバランサーに接続するよう指示する。
- (a) ウェブブラウザは、 OpenShift コンソールを公開する OpenShift コンソールロードバランサーに接続する。(b) このリクエストは、2つのopenshift-consoleポッドのうちの1つに送られる。
- openshift-console pod はパブリックネットワーク経由でクラスタマスターの OAuth サーバーポートに接続し、接続が認証済みかどうかを確認します。 リクエストがすでに認証されている場合は、 OpenShift ウェブコンソールへの接続が完了し、ウェブコンソールにアクセスできるようになります。 リクエストが認証されない場合、ユーザはクラスタマスタ上のクラスタOAuthサービスにリダイレクトされます。
- ウェブブラウザはクラスタのOAuthサーバポートに接続し、クライアントをIAMにリダイレクトする。
- ウェブブラウザはパブリックネットワーク経由でIAMに接続する。 ユーザーはパスワードを入力し、必要であれば 2FA。 このステップが成功すると、ユーザはクラスタのOAuthサーバにリダイレクトされます。
- ウェブブラウザはクラスタのOAuthサーバポートに再度接続する。 接続は OpenShift コンソールのロードバランサーにリダイレクトされる。
- ウェブブラウザは OpenShift コンソールを公開する OpenShift コンソールロードバランサーに接続する。 このリクエストは2つのopenshift-consoleポッドのうちの1つに送信され、再度クラスタマスターのOAuthサーバーポートに接続し、接続が認証済みかどうかを確認します。 ユーザーがパスワードを入力し、 2FA 認証を受けた場合、認証が有効化され、 OpenShift コンソールのメインウェブページに接続されます。
2.VPCとクラスタの構成を確認する
- ウェブブラウザがパブリックネットワークにアクセスできるようにして、クラスタ・アピサーバ、 OpenShift コンソール・ロードバランサ、IAM(
iam.cloud.ibm.com
とlogin.ibm.com
の両方を使用)に接続できるようにしてください - このクラスタまたはロードバランサのセキュリティグループ、ACL、またはCBR(Context-Base Restriction)ルールを変更した場合、このウェブブラウザからこれらのリソースへのトラフィックが許可されていることを確認してください
3.クラスター・データの収集
以下の手順に従って、トラブルシューティングに必要なクラスタ情報を収集します。 これらのコマンドで収集した出力は、後のステップで使用される。
-
クラスタAPIサーバを探す URL. 後のコマンドでは、この URL は
${CLUSTER_APISERVER_URL}
と呼ばれる。ibmcloud ks cluster get -c <cluster-id>
コマンドを実行します。ibmcloud oc cluster get -c <cluster-id>
- 出力の
Master
セクションで、URL
を見つける。 URL は以下の形式でなければならない:https://c<XXX>-e.<REGION>.containers.cloud.ibm.com:<YYYYY>
.
-
クラスタのOAuth URL を見つける。 後のコマンドでは、この URL は
${CLUSTER_OAUTH_URL}
と呼ばれる。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
- URL は以下の形式でなければならない:
https://c<XXX>-e.<REGION>.containers.cloud.ibm.com:<ZZZZZ>
.
-
Ingressのサブドメインを見つける。 後のコマンドでは、このサブドメインを
${CONSOLE_LOAD_BALANCER}
と呼ぶ。ibmcloud oc cluster get -c <CLUSTER-ID>
コマンドを実行します。ibmcloud oc cluster get -c <CLUSTER-ID>
- 出力から、以下の書式に一致するサブドメインを見つける:
<CLUSTER-NAME-PLUS-RANDOM-UNIQUE-STRING>.<REGION>.containers.appdomain.cloud
. カスタムのIngressサブドメインを設定した場合、フォーマットはカスタムの設定に合わせることに注意してください。
4.接続の確認とトラブルシューティング
以下の手順に従って、 接続フローに 記載されている接続を確認してください。 接続に問題が見つかった場合は、その情報を使って問題のトラブルシューティングを行ってください。
-
Ingressが正常であること、ルーターとコンソールポッドが正常であることを確認する。
- コマンドを実行する。
ibmcloud oc cluster get -c <CLUSTERID> ibmcloud oc ingress status-report get -c <CLUSTERID>
- 出力がエラーステータスを示す場合は、 Ingressのトラブルシューティング・ドキュメントを 使用して問題を解決してください。
- コマンドを実行する。
-
OpenShift クラスタ・オペレータが正常であることを確認します。
- コマンドを実行します。
oc get clusteroperators
- 出力にオペレータが健全でない、または現在のバージョンで実行されていないことが示されている場合は、 OpenShift クラスタ・バージョンのトラブルシューティング・ドキュメントを 使用して問題を解決します。 あるいは、 IBM と Red Hat のドキュメントを検索して、表示された特定のエラーを確認することもできます。
- コンソールオペレータが特に健全でない場合は、
openshift-console/console...
とopenshift-console-operator/console-operator...
のポッドログをチェックして、セキュリティグループ、ACL、または DNS のカスタマイズが、OAuth ポートまたは OpenShift コンソール URL へのポッドの接続を妨げていないかどうかを確認します。 セキュリティグループ、ACL、またはDNSが、接続を妨げるように設定されている可能性があります。
- コマンドを実行します。
-
クラスタマスタAPIサーバへの接続が成功していることを確認します。
- コマンドを実行します。 前のステップで 見つけたクラスタapiserver URL を指定します。
curl -k -vvv ${CLUSTER_APISERVER_URL}/version
- 接続が成功しない場合は、以下のチェックを行い、見つかった問題を解決してください。
ibmcloud oc cluster get -c <CLUSTER-ID>
コマンドを実行して、クラスタ・マスターが健全であることを確認します。 クラスタ・マスタの問題を解決する方法については、 マスタの健全性を確認するを 参照してください。- URL のホスト名部分がDNSで解決されていることを確認する。
dig $(echo ${CLUSTER_APISERVER_URL} | cut -d/ -f3 | cut -d: -f1)
コマンドを使用し、クラスタ API サーバ URL を指定します。 - クラスタ上のコンテキストベースの制限(CBR)ルールによって、クライアントがクラスタAPIサーバに接続できないかどうかを確認します。 パブリックCBRルールに、すべてのIPとサブネットを許可するネットワークゾーンを一時的に追加することで、これをテストできる。 この一時的な変更で問題が解決した場合は、トラフィックを許可するルールに必要な変更を加える。
- コマンドを実行します。 前のステップで 見つけたクラスタapiserver URL を指定します。
-
OpenShift コンソールを公開しているクラスターロードバランサーへの接続が成功していることを確認します。
- コマンドを実行します。 前のステップで 見つけたIngressサブドメインを指定する。
curl -k -vvv https://console-openshift-console.${CONSOLE_LOAD_BALANCER}/
- 接続が成功しない場合は、以下のチェックを行い、見つかった問題を解決してください。
- サブドメインのホスト名部分がDNSで解決されていることを確認する。
dig console-openshift-console.${CONSOLE_LOAD_BALANCER}
コマンドを使用します。 - ロードバランサーに適用されているセキュリティグループ、ACL、カスタムVPCルートを変更した場合、適用した変更やルールが接続を妨げていないか確認してください。 これらのコンポーネントを変更しておらず、デフォルト値を使用している場合は、このステップをスキップできます。
- サブドメインのホスト名部分がDNSで解決されていることを確認する。
- コマンドを実行します。 前のステップで 見つけたIngressサブドメインを指定する。
-
クラスタOAuthサーバへの接続が成功していることを確認します。
- コマンドを実行します。 前のステップで 見つけたクラスタOAuth URL を指定します。
curl -k -vvv ${CLUSTER_OAUTH_URL}/healthz
- 接続が成功しない場合は、以下のチェックを行い、見つかった問題を解決してください。
ibmcloud oc cluster get -c <CLUSTER-ID>
コマンドを実行して、クラスタ・マスターが健全であることを確認する。 クラスタ・マスタの問題を解決する方法については、 マスタの健全性を確認するを 参照してください。- クラスタ OAuth URL のホスト名部分が DNS 経由で解決されていることを確認します。
dig $(echo ${CLUSTER_OAUTH_URL} | cut -d/ -f3 | cut -d: -f1)
を使用し、クラスタ OAuth URL を指定します。 - クラスタ上のCBR (Context Based Restriction) ルールが、クライアントのクラスタOAuthサーバへの接続を妨げていないか確認します。 パブリックCBRルールに、すべてのIPとサブネットを許可するネットワークゾーンを一時的に追加することで、これをテストできる。 この一時的な変更で問題が解決した場合は、トラフィックを許可するルールに必要な変更を加える。
- コマンドを実行します。 前のステップで 見つけたクラスタOAuth URL を指定します。
-
IAMへの接続が成功したことを確認する。
- コマンドを実行する。
curl -vvv https://iam.cloud.ibm.com/healthz curl -vvv -o /dev/null -s https://login.ibm.com/
- これらのコマンドのいずれかに失敗した場合は、クライアントシステムがこれらのURLに確実に接続できること、およびURLがクライアントや企業のファイアウォールによってブロックされていないことを確認してください。 これらのURLは、公衆インターネットへのアクセスを必要とすることに注意してください。
- コマンドを実行する。
5.サポートへのお問い合わせ
上記の手順をすべて完了しても問題が解決しない場合は、サポートにご連絡ください。 サポート Case を開きます。 ケースの詳細には、関連するログファイル、エラーメッセージ、コマンド出力を必ず含めてください。