7.7. Pod の問題の調査
OpenShift Container Platform は、ホスト上に共にデプロイされる 1 つ以上のコンテナーである Pod の Kubernetes の概念を活用しています。Pod は、OpenShift Container Platform 4.12 で定義、デプロイ、および管理される最小のコンピュート単位です。
Pod が定義されると、コンテナーが終了するまで、またはコンテナーが削除されるまでノードで実行されるように割り当てられます。ポリシーおよび終了コードに応じて、Pod は終了または保持後に削除され、それらのログがアクセスできるようにします。
Pod の問題が発生した場合には、まず Pod のステータスをチェックします。Pod の明示的な障害が発生した場合には、Pod のエラー状態をチェックして、特定のイメージ、コンテナー、または Pod ネットワークの問題を特定してください。エラー状態に基づく診断データの収集を行います。Pod イベントメッセージおよび Pod およびコンテナーのログ情報を確認します。コマンドライン上で実行中の Pod にアクセスするか、問題のある Pod のデプロイメント設定に基づいて root アクセスでデバッグ Pod を起動して問題を動的に診断します。
7.7.1. Pod のエラー状態について
Pod の障害により、oc get Pods の出力の status フィールドで確認できる明示的なエラー状態が返されます。Pod のエラー状態は、イメージ、コンテナー、およびコンテナーネットワークに関連する障害に関する状態を示します。
以下の表は、Pod のエラー状態のリストをそれらの説明を記載しています。
| Pod のエラー状態 | 説明 |
|---|---|
|
| 一般的なイメージの取得エラー。 |
|
| イメージの取得に失敗し、取り消されました。 |
|
| 指定されたイメージ名は無効です。 |
|
| イメージの検査に失敗しました。 |
|
|
|
|
| レジストリーからイメージの取得を試みる際に、HTTP エラーが発生しました。 |
|
| 指定されたコンテナーが宣言された Pod 内にないか、kubelet によって管理されていません。 |
|
| コンテナーの初期化に失敗しました。 |
|
| Pod のコンテナーのいずれも正常に起動しませんでした。 |
|
| Pod のコンテナーのいずれも正常に強制終了されませんでした。 |
|
| コンテナーが終了しました。kubelet は再起動を試行しません。 |
|
| コンテナーまたはイメージが root 権限で実行を試行しました。 |
|
| Pod サンドボックスの作成が成功しませんでした。 |
|
| Pod サンドボックス設定を取得できませんでした。 |
|
| Pod サンドボックスは正常に停止しませんでした。 |
|
| ネットワークの初期化に失敗しました。 |
|
| ネットワークの終了に失敗しました。 |
7.7.2. Pod ステータスの確認
Pod のステータスおよびエラー状態をクエリーできます。Pod に関連するデプロイメント設定をクエリーし、ベースイメージの可用性を確認することもできます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。 -
skopeoがインストールされている。
手順
プロジェクトに切り替えます。
$ oc project <project_name>
namespace 内で実行されている Pod、Pod のステータス、エラーの状態、再起動、および経過時間をリスト表示します。
$ oc get pods
namespace がデプロイメント設定で管理されているかどうかを判別します。
$ oc status
namespace がデプロイメント設定で管理される場合、出力には、デプロイメント設定名とベースイメージの参照が含まれます。
前述のコマンドの出力で参照されているベースイメージを検査します。
$ skopeo inspect docker://<image_reference>
ベースイメージの参照が正しくない場合は、デプロイメント設定の参照を更新します。
$ oc edit deployment/my-deployment
デプロイメント設定が終了時に変更されると、設定が自動的に再デプロイされます。デプロイメントの進行中に Pod ステータスを確認し、問題が解決されているかどうかを判別します。
$ oc get pods -w
Pod の失敗に関連する診断情報は、namespace 内でイベントを確認します。
$ oc get events
7.7.3. Pod およびコンテナーログの検査
明示的な Pod の失敗に関連する警告およびエラーメッセージの有無について Pod およびコンテナーログを検査できます。ポリシーおよび終了コードによっては、Pod およびコンテナーログは Pod の終了後も利用可能のままになります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - API サービスが機能している。
-
OpenShift CLI (
oc) がインストールされている。
手順
特定の Pod のログをクエリーします。
$ oc logs <pod_name>
Pod 内の特定コンテナーのログをクエリーします。
$ oc logs <pod_name> -c <container_name>
前述の
oc logsコマンドを使用して取得されるログは、Pod またはコンテナー内の標準出力 (stdout) に送信されるメッセージで構成されます。Pod 内の
/var/log/に含まれるログを検査します。Pod 内の
/var/logに含まれるファイルおよびサブディレクトリーをリスト表示します。$ oc exec <pod_name> -- ls -alh /var/log
出力例
total 124K drwxr-xr-x. 1 root root 33 Aug 11 11:23 . drwxr-xr-x. 1 root root 28 Sep 6 2022 .. -rw-rw----. 1 root utmp 0 Jul 10 10:31 btmp -rw-r--r--. 1 root root 33K Jul 17 10:07 dnf.librepo.log -rw-r--r--. 1 root root 69K Jul 17 10:07 dnf.log -rw-r--r--. 1 root root 8.8K Jul 17 10:07 dnf.rpm.log -rw-r--r--. 1 root root 480 Jul 17 10:07 hawkey.log -rw-rw-r--. 1 root utmp 0 Jul 10 10:31 lastlog drwx------. 2 root root 23 Aug 11 11:14 openshift-apiserver drwx------. 2 root root 6 Jul 10 10:31 private drwxr-xr-x. 1 root root 22 Mar 9 08:05 rhsm -rw-rw-r--. 1 root utmp 0 Jul 10 10:31 wtmp
Pod 内の
/var/logに含まれる特定のログファイルをクエリーします。$ oc exec <pod_name> cat /var/log/<path_to_log>
出力例
2023-07-10T10:29:38+0000 INFO --- logging initialized --- 2023-07-10T10:29:38+0000 DDEBUG timer: config: 13 ms 2023-07-10T10:29:38+0000 DEBUG Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, playground, product-id, repoclosure, repodiff, repograph, repomanage, reposync, subscription-manager, uploadprofile 2023-07-10T10:29:38+0000 INFO Updating Subscription Management repositories. 2023-07-10T10:29:38+0000 INFO Unable to read consumer identity 2023-07-10T10:29:38+0000 INFO Subscription Manager is operating in container mode. 2023-07-10T10:29:38+0000 INFO
特定のコンテナー内の
/var/logに含まれるログファイルおよびサブディレクトリーをリスト表示します。$ oc exec <pod_name> -c <container_name> ls /var/log
特定のコンテナー内の
/var/logに含まれる特定のログファイルをクエリーします。$ oc exec <pod_name> -c <container_name> cat /var/log/<path_to_log>
7.7.4. 実行中の Pod へのアクセス
Pod 内でシェルを開くか、ポート転送によりネットワークアクセスを取得して、実行中の Pod を動的に確認することができます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - API サービスが機能している。
-
OpenShift CLI (
oc) がインストールされている。
手順
アクセスする Pod が含まれるプロジェクトに切り替えます。これは、
oc rshコマンドが-nnamespace オプションを受け入れないために必要です。$ oc project <namespace>
リモートシェルを Pod で起動します。
$ oc rsh <pod_name> 1- 1
- Pod に複数のコンテナーがある場合、
oc rshは-c <container_name>が指定されていない限り最初のコンテナーにデフォルト設定されます。
Pod 内の特定のコンテナーでリモートシェルを起動します。
$ oc rsh -c <container_name> pod/<pod_name>
Pod のポートへのポート転送セッションを作成します。
$ oc port-forward <pod_name> <host_port>:<pod_port> 1- 1
- ポート転送セッションをキャンセルするには、
Ctrl+Cを入力します。
7.7.5. root アクセスでのデバッグ Pod の起動
問題のある Pod のデプロイメントまたはデプロイメント設定に基づいて、root アクセスでデバッグ Pod を起動できます。通常、Pod ユーザーは root 以外の権限で実行しますが、問題を調査するために一時的な root 権限で Pod のトラブルシューティングを実行することは役に立ちます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - API サービスが機能している。
-
OpenShift CLI (
oc) がインストールされている。
手順
デプロイメントに基づいて、root アクセスでデバッグ Pod を起動します。
プロジェクトのデプロイメント名を取得します。
$ oc get deployment -n <project_name>
デプロイメントに基づいて、root 権限でデバッグ Pod を起動します。
$ oc debug deployment/my-deployment --as-root -n <project_name>
デプロイメント設定に基づいて、root アクセスでデバッグ Pod を起動します。
プロジェクトのデプロイメント設定名を取得します。
$ oc get deploymentconfigs -n <project_name>
デプロイメント設定に基づいて、root 権限でデバッグ Pod を起動します。
$ oc debug deploymentconfig/my-deployment-configuration --as-root -n <project_name>
インタラクティブなシェルを実行する代わりに、-- <command> を前述の oc debug コマンドに追加し、デバッグ Pod 内で個々のコマンドを実行することができます。
7.7.6. Pod およびコンテナーへの/からのファイルのコピー
Pod に/からファイルをコピーして、設定変更をテストしたり、診断情報を収集したりできます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - API サービスが機能している。
-
OpenShift CLI (
oc) がインストールされている。
手順
