7.3. CRI-O コンテナーランタイムの問題のトラブルシューティング

手順

1. デバッグ Pod 内で、ノードの crio systemd サービスをクエリーして CRI-O ステータスを確認します。

   1. ノードのデバッグ Pod を起動します。

      $ oc debug node/my-node

   2. /host をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の /host にホストの root ファイルシステムをマウントします。root ディレクトリーを /host に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。

      # chroot /host

      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.16 クラスターノードは、イミュータブルです。クラスターの変更を適用するには、Operator を使用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

   3. crio systemd サービスがノードでアクティブかどうかを確認します。

      # systemctl is-active crio

   4. より詳細な crio.service ステータスの要約を出力します。

      # systemctl status crio.service

手順

1. CRI-O journald ユニットログを収集します。以下の例は、クラスター内のすべてのコントロールプレーンノードからログを収集します。

   $ oc adm node-logs --role=master -u crio

2. 特定のノードから CRI-O journald ユニットログを収集します。

   $ oc adm node-logs <node_name> -u crio

3. API が機能しない場合は、代わりに SSH を使用してログを確認します。<node>.<cluster_name>.<base_domain> を適切な値に置き換えます。

   $ ssh core@<node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

   注記

   Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.16 クラスターノードは、イミュータブルです。クラスターの変更を適用するには、Operator を使用します。SSH を使用したクラスターノードへのアクセスは推奨されません。SSH 経由で診断データの収集を試行する前に、oc adm must gather およびその他の oc コマンドを実行して収集されるデータが十分であるかどうかを確認してください。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

手順

1. ノードで cordon を使用します。これは、ノードが Ready 状態になった場合に、ワークロードがスケジューリングされるのを防ぐためです。Status セクションに SchedulingDisabled と表示されていれば、スケジューリングが無効になっていることがわかります。

   $ oc adm cordon <node_name>

2. cluster-admin ユーザーとして、ノードをドレインします。

   $ oc adm drain <node_name> --ignore-daemonsets --delete-emptydir-data

   注記

   Pod または Pod テンプレートの terminateGracePeriodSeconds 属性は、正常な終了期間を制御します。この属性のデフォルトは 30 秒ですが、必要に応じてアプリケーションごとにカスタマイズできます。90 秒を超えて設定すると、Pod が SIGKILLed とマークされ、正常に終了しない可能性があります。

3. ノードが戻ってきたら、SSH またはコンソールでノードに接続し直します。その後、root ユーザーで接続します。

   $ ssh core@node1.example.com
   $ sudo -i

4. kubelet を手動で停止します。

   # systemctl stop kubelet

5. コンテナーや Pod を停止します。

   1. 以下のコマンドを使用して、HostNetwork にない Pod を停止します。これらが削除されるかどうかは、HostNetwork にあるネットワークプラグイン Pod に左右されるので、先に削除する必要があります。

      .. for pod in $(crictl pods -q); do if [[ "$(crictl inspectp $pod | jq -r .status.linux.namespaces.options.network)" != "NODE" ]]; then crictl rmp -f $pod; fi; done

   2. 他のすべての Pod を停止します。

      # crictl rmp -fa

6. crio のサービスを手動で停止します。

   # systemctl stop crio

7. これらのコマンドを実行すると、一時ストレージを完全に消去することができます。

   # crio wipe -f

8. crio および kubelet サービスを起動します。

   # systemctl start crio
   # systemctl start kubelet

9. crio および kubelet サービスが起動しており、ノードが Ready のステータスになっている場合には、クリーンアップが正常に機能したことが分かります。

   $ oc get nodes

   出力例

   NAME				    STATUS	                ROLES    AGE    VERSION
   ci-ln-tkbxyft-f76d1-nvwhr-master-1  Ready, SchedulingDisabled   master	 133m   v1.29.4

10. ノードをスケジューリング可能な状態にします。スケジューリングが有効になったことは、SchedulingDisabled のステータスがなくなったときにわかります。

    $ oc adm uncordon <node_name>

    出力例

    NAME				     STATUS	      ROLES    AGE    VERSION
    ci-ln-tkbxyft-f76d1-nvwhr-master-1   Ready            master   133m   v1.29.4