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) がインストールされている。

手順

  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.10 クラスターノードは変更できず、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

7.3.3. CRI-O の journald ユニットログの収集

CRI-O の問題が発生した場合には、ノードから CRI-O journald ユニットログを取得できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • API サービスが機能している。
  • OpenShift CLI (oc) がインストールされている。
  • コントロールプレーンまたはコントロールプレーンマシンの完全修飾ドメイン名がある。

手順

  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.10 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。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) がインストールされている。

手順

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

    $ oc adm cordon <nodename>
  2. cluster-admin ユーザーとして、ノードをドレインします。

    $ oc adm drain <nodename> --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.23.0

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

    $ oc adm uncordon <nodename>

    出力例

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