ワーカー・ノードのデバッグ

ステップ 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 の出力に含まれないシステムログやその他のノード固有のデータをレビューする必要があるかもしれない。

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

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

1. ワーカー・ノードをリストします。

   oc get nodes
   

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 Linux (RHCOS)を実行しているクラスタノードは不変であり、クラスタの変更を適用するにはオペレータに依存します。 CoreOS SSHを使用してクラスタノードにアクセスすることは推奨されません。 ただし、 OpenShift Container Platform APIが利用できない場合、またはkubeletがターゲット・ノード上で適切に機能していない場合、oc操作に影響が出る可能性がある。 このような状況では、代わりに ssh core@<node>.<cluster_name>.<base_domain>。

4. ツールボックスコンテナを起動する。このコンテナには、 sosreport を実行するために必要なバイナリとプラグインが含まれている。

   toolbox
   

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

5. 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
   

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

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