クラスタに関するヘルプとサポートの入手方法

クラスターに関するサポートオプション、トラブルシューティングのリソース、およびヘルプの入手方法をご覧ください。

サポート Case を開く前に、クラスター環境に関する関連情報を収集します。

診断・デバッグツールをお探しですか？ そのアドオンはもうサポートされていない。 IBM Cloud Monitoring はクラスタの問題を監視および診断するために推奨されます。 関連すると思われるその他のトラブルシューティングのリンクには、 クリティカルまたは NotReady 状態のワーカーノードのトラブルシューティングと、 IBM Cloud Kubernetes Service のアプリのトラブルシューティングが あります。

クラスタの詳細を取得する

  1. クラスターの詳細を取得します。

    ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID

  2. ワーカー・ノードに関する問題の場合は、ワーカー・ノードの詳細を取得します。

    1. クラスター内のすべてのワーカー・ノードをリストし、正常でない状態または状況のワーカー・ノードの ID をメモします。
        ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
    ```
2. 正常でないワーカー・ノードの詳細を取得します。

```sh {: pre}
    ibmcloud oc worker get -w WORKER_ID -c CLUSTER_NAME_OR_ID
    ```

  3. ポッドやサービスなどのクラスター内のリソースに関する問題の場合、クラスターにログインし、Kubernetes API を使用してそれらのリソースに関する詳細情報を取得します。

エラーログやその他の情報を収集する

must-gather コマンドの実行

oc adm must-gather CLIコマンドは、問題をデバッグするためにクラスタから情報を収集します。 このツールは、リソース定義、サービスログなどを収集する。 監査ログは、ファイルサイズを小さくするために、デフォルトの情報セットの一部として収集されないことに注意。

oc adm must-gather を実行すると、クラスタ上の新しいプロジェクトにランダムな名前の新しいポッドが作成される。 データはそのポッドで収集され、 must-gather.local で始まる新しいディレクトリに保存される。

以下のコマンド例を確認してください。

oc adm must-gather

1つまたは複数の特定の特徴に関連するデータを収集するコマンドの例では、特定の画像とともに --image 引数を使用します。

oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

監査ログを収集するコマンドの例。

oc adm must-gather -- /usr/bin/gather_audit_logs

特定のネームスペースでmust-gatherを実行するコマンドの例。

oc adm must-gather --run-namespace NAMESPACE \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

指定した時間からログを収集するコマンドの例。

oc adm must-gather --since=24h

oc adm must-gather --since-time=$(date -d '-24 hours' +%Y-%m-%dT%T.%9N%:z )

ネットワークログを収集するコマンドの例。

oc adm must-gather -- gather_network_logs

より多くの例と引数については、次のコマンドを実行してください

oc adm must-gather -h

must-gatherディレクトリから圧縮ファイルを作成するコマンド例。

tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/

圧縮ファイルをサポートケースに添付してください。

SOSレポートの収集

sosreport は、 (RHEL) および (RHCOS) システムの設定詳細、システム情報、診断データを収集するツールです。 Red Hat Enterprise Linux Red Hat Enterprise Linux CoreOS これは、ノードに関連する診断情報を収集するための標準化された方法を提供し、問題の診断のためにサポートに提供することができる。

サポートとのやり取りの中で、サポートが特定の OpenShift Container Platform ノードの sosreport アーカイブを収集するよう求めることがあります。 例えば、 oc adm must-gather の出力に含まれないシステムログやその他のノード固有のデータをレビューする必要があるかもしれない。

sosreport の取得方法は、ワーカーノードのオペレーティングシステムによって異なります。 RHCOSノードでは、 toolbox コマンドを使用します。 RHEL 8 および RHEL 9 のノードでは、 toolbox はサポートされていません。代わりに、 Red Hat の sosreport スクリプトを使用してください。

OpenShift Container Platform クラスターノードの sosreport を生成する推奨の方法は、デバッグポッドを使用することです。

Red Hat OpenShift クラスターにアクセスします。

  1. ワーカーノードの一覧を表示し、対象のノードとそのオペレーティングシステムを特定してください。

    oc get nodes -o wide

    sosreport を収集したいワーカーノードの名前をメモしておいてください。 「 OS-IMAGE 」列は、そのノードが RHCOS を実行しているか、RHEL を実行しているかを示します。

  2. ターゲットノードでデバッグセッションを開始します。

    oc debug node/node_name

    NoExecute のエフェクトで汚染されたターゲット・ノードでデバッグ・セッションに入るには、一時的なネームスペースにトレレーションを追加し、一時的なネームスペースでデバッグ・ポッドを起動する。

    oc new-project temp oc patch namespace temp --type=merge -p '{"metadata": {"annotations": { "scheduler.alpha.kubernetes.io/defaultTolerations": "[{\"operator\": \"Exists\"}]"}}}'

    oc debug node/my-cluster-node

  3. デバッグ・シェル内のルート・ディレクトリとして /host を設定する。 デバッグポッドは、ホストのルートファイルシステムをポッド内の /host にマウントします。 ルートディレクトリを /host`` に変更することで、ホストの実行可能パスに含まれるバイナリを実行できるようになります。

    chroot /host

    OpenShift Container Platform Red Hat Enterprise LinuxCoreOS (RHCOS) を実行するクラスターノードは不変であり、クラスター変更の適用にはオペレーターに依存します。 SSHを使用してクラスタノードにアクセスすることは推奨されません。 ただし、 OpenShift Container Platform API が利用できない場合、またはターゲットノード上で kubelet が正常に動作していない場合、oc operations に影響が生じる可能性があります。 このような状況では、代わりに ssh core@NODE.CLUSTER_NAME.BASE_DOMAIN。

  4. ワーカーノードのオペレーティングシステムに応じた方法を使用して、 sosreport を取得してください。

    • RHCOS ノード ： toolbox コマンドを使用します。

      1. ツールボックスコンテナを起動する。このコンテナには、 sosreport を実行するために必要なバイナリとプラグインが含まれている。 toolbox コマンドは、RHCOSノードでのみサポートされています。

        toolbox

        既存の toolbox ポッドがすでに実行されている場合、toolbox コマンドは 'toolbox-' already exists. Trying to start…. を出力します。実行中の toolbox コンテナを podman rm toolbox- で削除し、新しい toolbox コンテナを起動します。

      2. sos report コマンドを実行し、プロンプトに従ってトラブルシューティングデータを収集する。

        sos report -k crio.all=on -k crio.logs=on -k podman.all=on -k podman.logs=on

        OVN- Kubernetes ノードのネットワーク構成に関する情報をレポートに含めるためのコマンド例。

        sos report --all-logs

        sosreport の出力には、アーカイブの保存場所とチェックサムが表示されます。 以下の出力サンプルは、サポート・ケース ID 01234567 を参照しています。 ツールボックスコンテナがホストのルートディレクトリを /host`` にマウントしているため、ファイルパスは chroot 環境の外側になります。

        Your sosreport has been generated and saved in:
/host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
The checksum is: 382ffc167510fd71b4f12a4f40b97a4e

    • RHEL 8 および RHEL 9 ノード ：RHEL ノードでは、 toolbox コマンドはサポートされていません。 代わりに、 Red Hat の sosreport コレクションスクリプトを使用してください。

      1. Red Hat のナレッジベース記事に記載されている手順に従って、 Red Hat のsosreportスクリプトをダウンロードし、実行してください。

      2. スクリプトの指示に従って、トラブルシューティング用のデータを収集してください。 スクリプトの出力から、生成されたアーカイブファイルの保存場所を確認してください。

  5. sosreport をファイルに出力する。

    デバッグコンテナは、ホストのルートディレクトリを /host にマウントします。 連結の対象ファイルを指定する際は、 /host を含め、デバッグコンテナのルートディレクトリからの絶対パスを指定してください。

    oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz' > /tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz

    OpenShift Container Platform Red Hat Enterprise LinuxCoreOS (RHCOS) を実行するクラスターノードは不変であり、クラスター変更の適用にはオペレーターに依存します。 scp を使用してクラスタ・ノードから sosreport アーカイブを転送することは推奨されません。 ただし、 OpenShift Container Platform API が利用できない場合、またはターゲットノード上で kubelet が正常に動作していない場合、 oc 運用に影響が生じる可能性があります。 このような状況では、 scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path> を実行して、 sosreport アーカイブをノードからコピーすることができます。

  6. サポートケースにファイルをアップロードしてください。

サポート・ケースを開く

  1. IBM のサポートに、 サポートチケットを開いてお問い合わせください。

  2. 「 問題の種類 」では、「 Red Hat OpenShift on IBM Cloud 」を検索するか、選択してください。

  3. **「Case の詳細」**で、わかりやすいタイトルを入力し、事前に収集した詳細情報を記入します。 **「リソース」**から、この問題が起きているクラスターを選択することもできます。

  4. できるだけ具体的に、 IBM サポートが問題のトラブルシューティングを行う際に役立つと思われるアーキテクチャー図や補足資料を含めてください。