7.3. CRI-O コンテナーランタイムの問題のトラブルシューティング
7.3.1. CRI-O コンテナーランタイムエンジンについて
CRI-O は Kubernetes ネイティブコンテナーランタイム実装です。これはオペレーティングシステムに密接に統合し、Kubernetes の効率的で最適化されたエクスペリエンスを提供します。CRI-O は、コンテナーを実行、停止および再起動を実行するための機能を提供します。
CRI-O コンテナーランタイムエンジンは、各 OpenShift Container Platform クラスターノードで systemd サービスを使用して管理されます。コンテナーランタイムの問題が発生する場合は、各ノードの crio
systemd サービスのステータスを確認します。マニフェストコンテナーランタイムの問題のあるノードから CRI-O の journald ユニットログを収集します。
7.3.2. CRI-O ランタイムエンジンのステータスの確認
各クラスターノードで CRI-O コンテナーランタイムエンジンのステータスを確認できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
デバッグ Pod 内で、ノードの
crio
systemd サービスをクエリーして CRI-O ステータスを確認します。ノードのデバッグ Pod を起動します。
$ oc debug node/my-node
/host
をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にホストの root ファイルシステムをマウントします。root ディレクトリーを/host
に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。# chroot /host
注記Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.7 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、
oc
操作がその影響を受けます。この場合は、代わりにssh core@<node>.<cluster_name>.<base_domain>
を使用してノードにアクセスできます。crio
systemd サービスがノードでアクティブかどうかを確認します。# systemctl is-active crio
より詳細な
crio.service
ステータスの要約を出力します。# systemctl status crio.service
7.3.3. CRI-O の journald ユニットログの収集
CRI-O の問題が発生した場合には、ノードから CRI-O journald ユニットログを取得できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - API サービスが機能している。
-
OpenShift CLI (
oc
) がインストールされている。 - コントロールプレーンまたはコントロールプレーンマシン (別名マスターマシン) の完全修飾ドメイン名がある。
手順
CRI-O journald ユニットログを収集します。以下の例は、クラスター内のすべてのコントロールプレーンノードからログを収集します。
$ oc adm node-logs --role=master -u crio
特定のノードから CRI-O journald ユニットログを収集します。
$ oc adm node-logs <node_name> -u crio
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.7 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。SSH 経由で診断データの収集を試行する前に、
oc adm must gather
およびその他のoc
コマンドを実行して収集されるデータが十分であるかどうかを確認してください。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc
操作がその影響を受けます。この場合は、代わりにssh core@<node>.<cluster_name>.<base_domain>
を使用してノードにアクセスできます。
7.3.4. CRI-O ストレージの消去
以下の問題が発生した場合、CRI-O の一時ストレージを手動でクリアすることができます。
ノードがどの Pod でも実行できず、このエラーが表示される。
Failed to create pod sandbox: rpc error: code = Unknown desc = failed to mount container XXX: error recreating the missing symlinks: error reading name of symlink for XXX: open /var/lib/containers/storage/overlay/XXX/link: no such file or directory
作業ノードに新しいコンテナーを作成することができず、can't stat lower layer というエラーが表示される。
can't stat lower layer ... because it does not exist. Going through storage to recreate the missing symlinks.
-
クラスターをアップグレードした後、またはノードを再起動しようとすると、ノードが
NotReady
状態になる。 -
コンテナーランタイム実装
(crio
) が正しく動作していない。 -
コンテナーランタイムインスタンス
(crio
) が動作していないため、oc debug node/<nodename>
を使用してノード上でデバッグシェルを開始することができまない。
この手順で、CRI-O のストレージを完全に消去し、エラーを解消してください。
前提条件:
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
ノードで
cordon
を使用します。これは、ノードがReady
状態になった場合に、ワークロードがスケジューリングされるのを防ぐためです。Status セクションにSchedulingDisabled
と表示されていれば、スケジューリングが無効になっていることがわかります。$ oc adm cordon <nodename>
cluster-admin ユーザーとして、ノードをドレインします。
$ oc adm drain <nodename> --ignore-daemonsets --delete-emptydir-data
注記Pod または Pod テンプレートの
terminateGracePeriodSeconds
属性は、正常な終了期間を制御します。この属性のデフォルトは 30 秒ですが、必要に応じてアプリケーションごとにカスタマイズできます。90 秒を超えて設定すると、Pod がSIGKILLed
とマークされ、正常に終了しない可能性があります。ノードが戻ってきたら、SSH またはコンソールでノードに接続し直します。その後、root ユーザーで接続します。
$ ssh core@node1.example.com $ sudo -i
kubelet を手動で停止します。
# systemctl stop kubelet
コンテナーや Pod を停止します。
# crictl rmp -fa
crio のサービスを手動で停止します。
# systemctl stop crio
これらのコマンドを実行すると、一時ストレージを完全に消去することができます。
# crio wipe -f
crio および kubelet サービスを起動します。
# systemctl start crio # systemctl start kubelet
crio および kubelet サービスが起動しており、ノードが
Ready
のステータスになっている場合には、クリーンアップが正常に機能したことが分かります。$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ci-ln-tkbxyft-f76d1-nvwhr-master-1 Ready, SchedulingDisabled master 133m v1.22.0-rc.0+75ee307
ノードをスケジューリング可能な状態にします。スケジューリングが有効になったことは、
SchedulingDisabled
のステータスがなくなったときにわかります。$ oc adm uncordon <nodename>
出力例
NAME STATUS ROLES AGE VERSION ci-ln-tkbxyft-f76d1-nvwhr-master-1 Ready master 133m v1.22.0-rc.0+75ee307