7.7. Pod の問題の調査

OpenShift Container Platform は、ホスト上に共にデプロイされる 1 つ以上のコンテナーである Pod の Kubernetes の概念を活用しています。Pod は、OpenShift Container Platform 4.9 で定義され、デプロイされ、管理される最小のコンピュート単位です。

Pod が定義されると、コンテナーが終了するまで、またはコンテナーが削除されるまでノードで実行されるように割り当てられます。ポリシーおよび終了コードに応じて、Pod は終了または保持後に削除され、それらのログがアクセスできるようにします。

Pod の問題が発生した場合には、まず Pod のステータスをチェックします。Pod の明示的な障害が発生した場合には、Pod のエラー状態をチェックして、特定のイメージ、コンテナー、または Pod ネットワークの問題を特定してください。エラー状態に基づく診断データの収集を行います。Pod イベントメッセージおよび Pod およびコンテナーのログ情報を確認します。コマンドライン上で実行中の Pod にアクセスするか、または問題のある Pod のデプロイメント設定に基づいて root アクセスでデバッグ Pod を起動して問題を動的に診断します。

7.7.1. Pod のエラー状態について

Pod の障害により、oc get Pods の出力の status フィールドで確認できる明示的なエラー状態が返されます。Pod のエラー状態は、イメージ、コンテナー、およびコンテナーネットワークに関連する障害についての状態を示します。

以下の表は、Pod のエラー状態の一覧をそれらの説明を記載しています。

表7.2 Pod のエラー状態

Pod のエラー状態説明

ErrImagePull

一般的なイメージの取得エラー。

ErrImagePullBackOff

イメージの取得に失敗し、取り消されました。

ErrInvalidImageName

指定されたイメージ名は無効です。

ErrImageInspect

イメージの検査に失敗しました。

ErrImageNeverPull

PullPolicy は NeverPullImage に設定され、ターゲットイメージはホスト上でローカルに見つかりません。

ErrRegistryUnavailable

レジストリーからイメージの取得を試みる際に、HTTP エラーが発生しました。

ErrContainerNotFound

指定されたコンテナーが宣言された Pod 内にないか、または kubelet によって管理されていません。

ErrRunInitContainer

コンテナーの初期化に失敗しました。

ErrRunContainer

Pod のコンテナーのいずれも正常に起動しませんでした。

ErrKillContainer

Pod のコンテナーのいずれも正常に強制終了されませんでした。

ErrCrashLoopBackOff

コンテナーが終了しました。kubelet は再起動を試行しません。

ErrVerifyNonRoot

コンテナーまたはイメージが root 権限で実行を試行しました。

ErrCreatePodSandbox

Pod サンドボックスの作成が成功しませんでした。

ErrConfigPodSandbox

Pod サンドボックス設定を取得できませんでした。

ErrKillPodSandbox

Pod サンドボックスは正常に停止しませんでした。

ErrSetupNetwork

ネットワークの初期化に失敗しました。

ErrTeardownNetwork

ネットワークの終了に失敗しました。

7.7.2. Pod ステータスの確認

Pod のステータスおよびエラー状態をクエリーできます。Pod に関連するデプロイメント設定をクエリーし、ベースイメージの可用性を確認することもできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • skopeo がインストールされている。

手順

  1. プロジェクトに切り替えます。 

    $ oc project <project_name>

  2. namespace 内で実行されている Pod、Pod のステータス、エラーの状態、再起動、および経過時間を一覧表示します。 

    $ oc get pods

  3. namespace がデプロイメント設定で管理されているかどうかを判別します。 

    $ oc status

    namespace がデプロイメント設定で管理される場合、出力には、デプロイメント設定名とベースイメージの参照が含まれます。

  4. 前述のコマンドの出力で参照されているベースイメージを検査します。 

    $ skopeo inspect docker://<image_reference>

  5. ベースイメージの参照が正しくない場合は、デプロイメント設定の参照を更新します。 

    $ oc edit deployment/my-deployment

  6. デプロイメント設定が終了時に変更されると、設定が自動的に再デプロイされます。デプロイメントの進行中に Pod ステータスを確認し、問題が解決されているかどうかを判別します。 

    $ oc get pods -w

  7. Pod の失敗に関連する診断情報については、namespace 内でイベントを確認します。 

    $ oc get events

7.7.3. Pod およびコンテナーログの検査

明示的な Pod の失敗に関連する警告およびエラーメッセージの有無について Pod およびコンテナーログを検査できます。ポリシーおよび終了コードによっては、Pod およびコンテナーログは Pod の終了後も利用可能のままになります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • API サービスが機能している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 特定の Pod のログをクエリーします。 

    $ oc logs <pod_name>

  2. Pod 内の特定コンテナーのログをクエリーします。 

    $ oc logs <pod_name> -c <container_name>

    前述の oc logs コマンドを使用して取得されるログは、Pod またはコンテナー内の標準出力 (stdout) に送信されるメッセージで設定されます。

  3. Pod 内の /var/log/ に含まれるログを検査します。

    1. Pod 内の /var/log に含まれるファイルおよびサブディレクトリーを一覧表示します。 

      $ oc exec <pod_name> ls -alh /var/log

    2. Pod 内の /var/log に含まれる特定のログファイルをクエリーします。 

      $ oc exec <pod_name> cat /var/log/<path_to_log>

    3. 特定のコンテナー内の /var/log に含まれるログファイルおよびサブディレクトリーを一覧表示します。 

      $ oc exec <pod_name> -c <container_name> ls /var/log

    4. 特定のコンテナー内の /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) がインストールされている。

手順

  1. アクセスする Pod が含まれるプロジェクトに切り替えます。これは、oc rsh コマンドが -n namespace オプションを受け入れないために必要です。 

    $ oc project <namespace>

  2. リモートシェルを Pod で起動します。 

    $ oc rsh <pod_name>  1
    1
    Pod に複数のコンテナーがある場合、oc rsh は -c <container_name> が指定されていない限り最初のコンテナーにデフォルト設定されます。

  3. Pod 内の特定のコンテナーでリモートシェルを起動します。 

    $ oc rsh -c <container_name> pod/<pod_name>

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

手順

  1. デプロイメントに基づいて、root アクセスでデバッグ Pod を起動します。

    1. プロジェクトのデプロイメント名を取得します。 

      $ oc get deployment -n <project_name>

    2. デプロイメントに基づいて、root 権限でデバッグ Pod を起動します。 

      $ oc debug deployment/my-deployment --as-root -n <project_name>

  2. デプロイメント設定に基づいて、root アクセスでデバッグ Pod を起動します。

    1. プロジェクトのデプロイメント設定名を取得します。 

      $ oc get deploymentconfigs -n <project_name>

    2. デプロイメント設定に基づいて、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) がインストールされている。

手順

  1. ファイルを Pod にコピーします。 

    $ oc cp <local_path> <pod_name>:/<path> -c <container_name>  1
    1
    -c オプションが指定されていない場合、Pod の最初のコンテナーが選択されます。

  2. Pod からファイルをコピーします。 

    $ oc cp <pod_name>:/<path>  -c <container_name><local_path>  1
    1
    -c オプションが指定されていない場合、Pod の最初のコンテナーが選択されます。
    注記

    oc cp が機能するには、tar バイナリーがコンテナー内で利用可能である必要があります。