Red Hat OpenShift Web コンソール、OperatorHub、内部レジストリー、およびその他のコンポーネントのデバッグ

仮想プライベートクラウド クラシック・インフラストラクチャー

Red Hat OpenShift クラスターには、開発者エクスペリエンスをシンプルにする標準装備コンポーネントがいくつもあります。 例えば、Red Hat OpenShift Web コンソールを使用してクラスターのワークロードの管理やデプロイを行ったり、OperatorHub にあるサード・パーティーのオペレーターを有効にしてサービス・メッシュやその他の機能でクラスターを機能拡張したりできます。

よく使用されるコンポーネントには、以下のようなものがあります。 これらのコンポーネントに問題が発生した場合は、以下のデバッグ手順を参照してください。

  • openshift-console プロジェクト内の Red Hat OpenShift Web コンソール
  • ** プロジェクトの **OperatorHubopenshift-marketplace
  • ** プロジェクトの**内部レジストリーopenshift-image-registry

ステップ 1: アカウントのセットアップを確認する

IBM Cloud アカウントが正しくセットアップされていることを確認してください。 デフォルトのコンポーネントが正常に実行できない状況としてよくあるのは、次のような状況です。

  • クラシック・クラスターに複数のゾーンがある場合、または VPC クラスターを使用している場合は、VRF または VLAN スパンニングを有効にしておく必要があります。 VRF が既に有効になっているかどうかを確認するには、ibmcloud account show を実行します。 VLAN スパンニングが有効になっているかどうかを確認するには、ibmcloud oc vlan spanning get を実行します。
  • アカウントユーザーの一部が TOTP などの多要素認証（MFA）を使用している場合は、 IBM Cloud アカウント内のすべてのユーザーに対して MFAを有効にして ください。

ユーザー・レベルでの MFA の有効化はサポートされていません。 一部のユーザーに対して MFA が有効になっているが、アカウント・レベルですべてのユーザーに対して有効になっていない場合、認証エラーが発生する可能性があります。

ステップ 2: パブリック・ゲートウェイを確認する

  • パブリック・クラウド・サービス・エンドポイントとプライベート・クラウド・サービス・エンドポイントが有効になっている VPC クラスターの場合:

    クラスターが接続されている各 VPC サブネットでパブリック・ゲートウェイが有効になっていることを確認します。 Web コンソールや OperatorHub などのデフォルト・コンポーネントが、セキュアなパブリック接続を使用して、リモートのプライベート・レジストリーからイメージをプルするなどのアクションを実行するためには、パブリック・ゲートウェイが必要です。

    1. IBM Cloud コンソールまたは CLI を使用して、クラスターの接続先の各サブネット上でパブリック・ゲートウェイが有効になっていることを確認します。
    2. Web コンソールで、Developer catalog のコンポーネントを再始動します。
      1. サンプル・オペレーターの構成マップを編集します。
        oc edit configs.samples.operator.openshift.io/cluster
    3. managementState の値を Removed から Managed に変更します。 3. 構成マップを保存して閉じます。 変更が自動的に適用されます。

  • パブリック・クラウド・サービス・エンドポイントとプライベート・クラウド・サービス・エンドポイントの両方が有効になっているクラシック・クラスターの場合:

    ネットワーク・コンポーネントがデプロイ時にマスターと通信するためのパブリック接続がクラスターにあることを確認します。

    1. 「Master Status」を確認します。 「Master Status」が「Ready」でない場合は、状況を確認し、トラブルシューティング情報に従って問題を解決してください。
        ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
    ```
1. **マスター・ステータス**出力で、クラスターに**パブリック・サービス・エンドポイント URL** があることを確認します。 クラスターにパブリッククラウドサービスのエンドポイントがない場合は、有効にしてください。
1. クラスター内の少なくともいくつかのワーカー・ノードに**パブリック IP** アドレスがあることを確認します。 どのワーカーノードも対応していない場合は、少なくとも1つのワーカープールに対してパブリックVLANを設定する必要があります。

```sh {: pre}
    ibmcloud oc workers -c CLUSTER_NAME_OR_ID
    ```

ステップ 3: ファイアウォールおよびネットワーク・ポリシーを確認する

すべてのファイアウォールまたはネットワーク・ポリシーを調べて、OperatorHub またはその他の Red Hat OpenShift コンポーネントの着信トラフィックまたは発信トラフィックをブロックしていないことを確認します。

ステップ 4: クラスターのセットアップを確認する

クラスターが正しくセットアップされていることを確認します。 クラスターを作成したばかりの場合は、クラスター・コンポーネントが完全にプロビジョンされるまで待ちます。

  1. クラスターの詳細を取得します。
    ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
  2. 先ほどのステップの出力を確認し、Ingress Subdomain を調べます。
  3. クラスターが最新のパッチ・バージョンを実行していることを確認します。 クラスターで最新のパッチ・バージョンが実行されていない場合は、クラスターとワーカー・ノードを更新します。
    1. クラスターのメジャー・バージョンおよびマイナー・バージョンにとって最新のパッチ・バージョンに、クラスター・マスターを更新します。
        ibmcloud oc cluster master update -c CLUSTER_NAME_OR_ID --version MAJOR.MINOR_openshift-f
    ```
2. ワーカー・ノードをリストします。
```sh {: pre}
    ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
    ```
3. クラスター・マスターのバージョンと一致するように[ワーカー・ノードを更新](/docs/openshift?topic=openshift-update#worker_node)します。
```sh {: pre}
    ibmcloud oc worker update -c CLUSTER_NAME_OR_ID -w WORKER1_ID -w WORKER2_ID -w WORKER3_ID
    ```
  4. クラスターの状態を確認します。 状態が正常でない場合は、クラスタの状態を確認し、問題があれば解決してください。
  5. 「Master health」を確認します。 状態が正常でない場合は、マスターの健康状態を確認し、問題があれば解決する。
  6. Red Hat OpenShift コンポーネントが実行される可能性のあるワーカー・ノードを確認します。 状態が**「normal」**でない場合は、ワーカー・ノードのデバッグを参照してください。
    ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID

ステップ 5: クラスターにログインする

クラスターにログインします。 Red Hat OpenShift Web コンソールがログイン・トークンを取得できない場合は、CLI からクラスターにアクセスすることができます。

VPC のみ: プライベートクラウド・サービス・エンドポイントを有効にした場合は、VPC の VPN 接続を使用してプライベート・ネットワークに接続し、Web コンソールにアクセスする必要があります。

ステップ 6: コンポーネント・ポッドを確認する

動作しない Red Hat OpenShift コンポーネント・ポッドの正常性を確認します。

  1. ポッドの状況を確認します。
    oc get pods -n <project>
  2. ポッドが Running 状況でない場合は、ポッドの詳細を表示し、各イベントを確認します。 例えば、CPU またはメモリーのリソースが不足しているためにポッドをスケジュールできないというエラーが表示される場合があります。これは、ワーカー・ノードが 3 台未満のクラスターではよくあることです。 クラシック・ワーカー・プールのサイズを変更 するか、 VPC ワーカー・プールのサイズを変更 して、再試行してください。
    oc describe pod -n <project> <pod>
  3. イベント・セクションに役立つ情報が表示されない場合は、ポッド・ログでエラー・メッセージやその他のトラブルシューティング情報を確認してください。
    oc logs pod -n <project> <pod>
  4. ポッドを再始動して、Running 状況になるかどうかを確認します。
    oc delete pod -n <project> <pod>

ステップ 7: システム・ポッドを確認する

ポッドが正常な場合は、他のシステム・ポッドで問題が発生していないか確認します。 時により、別のコンポーネントが正常であることが、正常に機能するために必要になるコンポーネントがあります。

例えば、OperatorHub の一連のイメージは、quay.io などの外部レジストリーに保管されています。 Red Hat OpenShift クラスターのプロジェクト間で使用するときには、これらのイメージが内部レジストリーにプルされます。 許可またはコンピュート・リソースの不足などの理由で、OperatorHub または内部レジストリー・コンポーネントのいずれかが適切にセットアップされていない場合、OperatorHub およびカタログは表示されません。

  1. 保留中のポッドがあるかどうかを確認します。
    oc get pods --all-namespaces | grep Pending
  2. ポッドの詳細を表示し、イベントを確認します。
    oc describe pod -n <project_name> <pod_name>
    例えば、 openshift-image-registry ポッドでよく表示されるメッセージには、以下のようなものがあります。
    • 正しいストレージ権限なしでクラスターを作成したため、Volume could not be created エラー・メッセージが表示されました。Red Hat OpenShift on IBM Cloud クラスターには、システムおよび他のポッドのイメージを保管するためのファイル・ストレージ・デバイスがデフォルトで付属しています。 インフラストラクチャー許可を修正し、ポッドを再始動してください。
    • order will exceed maximum number of storage volumes allowed エラー・メッセージ。これは、1 アカウントに許可されるファイル・ストレージとブロック・ストレージのデバイスの合計のクォータを超えたことが原因です。 未使用のストレージ・デバイスの削除または ストレージのクォータを増やし、ポッドを再始動してください。
    • ファイル・ストレージ・デバイスがいっぱいであるため、イメージを保管できないというメッセージです。 ストレージ・デバイスのサイズを変更し、ポッドを再始動してください。
    • 内部レジストリーが外部レジストリーからイメージをプルできないため、Pull image still failed due to error: unauthorized: authentication required エラー・メッセージが表示されます。 プロジェクトにイメージ・プル・シークレットが設定されていることを確認し、ポッドを再始動してください。
  3. 障害のあるポッドを実行しているノードを確認します。 それらのポッドのすべてが同じワーカー・ノードで実行されている場合は、そのワーカー・ノードにネットワーク接続の問題が生じている可能性があります。 ワーカー・ノードを再ロードします。
    ibmcloud oc worker reload -c CLUSTER_NAME_OR_ID -w WORKER_NODE_ID

手順 8：VPN を確認する

クラスタ内のVPNが正しく設定されていることを確認してください。

  1. VPNポッドが「 実行中 」の状態であることを確認してください。
    oc get pods -n kube-system -l app=vpn
  2. VPNのログを確認し、VPNトンネルが機能していないことを示す「 ERROR 」というメッセージ（例： WORKERIP:<port>、WORKERIP:10250 など）がないか確認してください。
    oc logs -n kube-system <vpn_pod> --tail 10
  3. ワーカー IP エラーが表示された場合、ワーカー間の通信が切断されていないか確認します。 calico-node プロジェクト内の calico-system ポッドにログインし、同じ WORKERIP:10250 エラーがないか確認してください。
    oc exec -n calico-system <calico-node_pod> -- date
  4. ワーカー間の通信が切断されている場合は、VRF または VLAN スパンニングを有効にします。
  5. VPNポッドまたは calico-node ポッドのいずれかから、これとは異なるエラーが表示された場合は、VPNポッドを再起動してください。
    oc delete pod -n kube-system <vpn_pod>
  6. それでもVPNが接続できない場合は、ポッドが実行されているワーカーノードを確認してください。
    oc describe pod -n kube-system <vpn_pod> | grep "Node:"
  7. ワーカーノードをCordonで隔離し、VPNポッドが別のワーカーノードに再スケジューリングされるようにします。
    oc cordon <worker_node>
  8. VPNポッドのログをもう一度確認してください。 ポッドにエラーが表示されなくなった場合は、ワーカー・ノードにネットワーク接続の問題があった可能性があります。 ワーカー・ノードを再ロードします。
    ibmcloud oc worker reload -c CLUSTER_NAME_OR_ID -w WORKER_NODE_ID

ステップ 9: クラスター・マスターをリフレッシュする

クラスター・マスターをリフレッシュして、デフォルトの Red Hat OpenShift コンポーネントをセットアップします。 クラスターをリフレッシュした後、操作が完了するまで数分待ってください。

ibmcloud oc cluster master refresh -c CLUSTER_NAME_OR_ID

ステップ 10: 再試行する

Red Hat OpenShift コンポーネントをもう一度使用してみます。

まだエラーがある場合は、フィードバック、質問、およびサポートを参照してください。