ステップ 1: ワーカー・ノードの状態を取得する

クラスターが Critical、Delete failed、または Warning 状態の場合、あるいは Pending 状態が長時間続いている場合は、ワーカー・ノードの状態を確認してください。

ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID

ステップ 2: ワーカー・ノードの状態を確認する

CLI 出力内ですべてのワーカー・ノードの State フィールドと Status フィールドを確認します。

詳しくは、ワーカー・ノードの状態を参照してください。

ステップ 3: 各ワーカー・ノードの詳細を取得する

ワーカー・ノードの詳細情報を取得します。 詳細情報にエラー・メッセージが含まれている場合は、ワーカー・ノードに関する一般的なエラー・メッセージのリストを参照して、問題の解決方法を確認してください。

ibmcloud oc worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_NODE_ID

ステップ 4: ワーカー・ノードのインフラストラクチャー・プロバイダーを確認する

インフラストラクチャー環境を確認して、ワーカー・ノードの問題の原因になっている他の理由があるかどうかを調べます。

1. ネットワーキング・チームに問い合わせて、ファイアウォールやサブネットの更新などの最近の保守がワーカー・ノード接続に影響していないかどうかを確認します。
2. レビュー IBM Cloud 対象： Red Hat OpenShift on IBM Cloud および基盤となるインフラストラクチャプロバイダー（例： Virtual Servers クラシック版や VPC 関連のコンポーネントについては、あるいは Satellite など。
3. 基礎となるインフラストラクチャー (クラシックの Virtual Servers など) に対するアクセス権限がある場合は、ワーカー・ノードに対応するマシンの詳細を確認します。

ステップ 5: ワーカーノードに関するログやその他の詳細を収集する

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. サポートケースにファイルをアップロードしてください。