Pod の起動障害とランタイムエラーのトラブルシューティング方法 - ACS

Pod の起動に失敗した場合、繰り返しクラッシュする場合、または予期しない動作をする場合は、このガイドを使用して根本原因を特定し、問題を解決してください。

診断ワークフロー

Diagnostic workflow

Pod のステータスを確認します。ステータスが Running 以外の場合は、「Pod ステータスリファレンス」で対象のソリューションをご参照ください。
Pod が Running 状態であるものの期待どおりに動作しない場合は、「Running 状態だが期待どおりに動作しない Pod」をご参照ください。
Pod が Out-of-Memory (OOM) エラーで終了した場合は、「OOM エラーのトラブルシューティング」をご参照ください。
トラブルシューティング後も問題が解決しない場合は、チケットを送信。

Pod ステータスリファレンス

ステータス	意味	ソリューション
Pending	ノードにスケジュールされていない	Pending 状態でスタックした Pod
Init:N/M	M 個の init コンテナのうち N 個が起動した	init コンテナの状態でスタックした Pod
Init:Error	init コンテナが失敗した	init コンテナの状態でスタックした Pod
Init:CrashLoopBackOff	init コンテナがクラッシュループに陥っている	init コンテナの状態でスタックした Pod
ImagePullBackOff	コンテナイメージのプルに失敗した	ImagePullBackOff 状態でスタックした Pod
CrashLoopBackOff	アプリケーションが繰り返しクラッシュしている	CrashLoopBackOff 状態でスタックした Pod
Completed	起動コマンドの完了後、すべてのコンテナが終了した	Completed 状態でスタックした Pod
Running	Pod が期待どおりに動作している、または Running 状態だが期待どおりに動作していない	Running 状態だが期待どおりに動作しない Pod
Terminating	削除中	Terminating 状態でスタックした Pod

診断ツール

すべての診断ツールは、ACS コンソールで利用できます。まず、Pod に移動してください。

ACS コンソールにログオンします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
クラスターリスト ページで、対象クラスターの名前をクリックします。左側のナビゲーションウィンドウで、Workloads > Pods を選択します。
[Pod] ページの左上隅で、Pod が属する [名前空間] を選択します。リストから対象の Pod を見つけます。

次に、以下のいずれかのツールを使用します。

Pod 詳細の表示

Pod 名をクリックするか、[操作] 列の [詳細の表示] をクリックして、Pod 名、イメージ、IP アドレスなどの情報を表示します。

Pod 構成 (YAML) の表示

Pod 詳細ページを開き、右上隅の [編集] をクリックして、Pod の YAML ファイルと構成を表示します。

Pod イベントの表示

Pod 詳細ページを開き、下部セクションの [イベント] タブをクリックします。

説明

Kubernetes はデフォルトで過去 1 時間のイベントを保持します。イベントをより長期間保持するには、イベントセンターを作成して使用してください。

Pod ログの表示

Pod 詳細ページを開き、下部セクションの [ログ] タブをクリックします。

説明

Alibaba Cloud Container Compute Service (ACS) は、Simple Log Service と統合されています。クラスターを作成する際に Simple Log Service を有効化すると、標準出力およびテキストファイルからログデータを収集できます。詳細については、「Pod の環境変数を使用してアプリケーションログを収集する」をご参照ください。

Pod モニタリングの表示

ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
[Prometheus モニタリング] ページで、[クラスター概要] タブをクリックして、Pod の CPU 使用率、メモリ使用量、ネットワーク I/O を表示します。

コンテナターミナルへの接続

ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。

Pod 診断の実行

[Pod] ページで対象の Pod を見つけ、[操作] 列の [診断] をクリックします。完了後に診断結果を確認します。詳細については、「クラスター診断の操作」をご参照ください。

Pending 状態でスタックした Pod

Pending 状態の Pod は、どのノードにもスケジュールされていません。これは通常、必要なリソースが不足しているか、クォータ構成が無効な場合に発生します。

問題の診断：

Pod イベントを確認して、スケジューリング失敗の原因を特定します。一般的な原因は次のとおりです。

リソース依存関係の欠如：一部の Pod は、ConfigMap や永続ボリューム要求 (PVC) などの特定のクラスターリソースに依存します。たとえば、PVC は Pod の spec で使用される前に、永続ボリューム (PV) にバインドされている必要があります。
無効なクォータ構成：Pod のリソースリクエストが利用可能なクォータを超えている可能性があります。詳細については、Pod イベントと監査ログを確認してください。

init コンテナの状態でスタックした Pod

これらの状態は、1 つ以上の init コンテナが完了できなかったことを示します。

Init:N/M -- Pod には M 個の init コンテナがあり、そのうち N 個が起動し、M-N 個が失敗したことを示します。
Init:Error -- init コンテナがエラーで終了したことを示します。
Init:CrashLoopBackOff -- init コンテナがクラッシュと再起動を繰り返していることを示します。

問題の診断：

Pod イベントで、失敗した init コンテナのエラーを確認します。「Pod イベントの表示」をご参照ください。
失敗した init コンテナのログで、エラーの詳細を確認します。「Pod ログの表示」をご参照ください。
Pod の YAML で init コンテナの構成が正しいことを確認します。「Pod 構成 (YAML) の表示」をご参照ください。init コンテナのデバッグに関する詳細については、「init コンテナのデバッグ」をご参照ください。

ImagePullBackOff 状態でスタックした Pod

Pod はスケジュールされていますが、1 つ以上のコンテナイメージをプルできません。Pod イベントを確認して、どのイメージが失敗したかを特定します。

問題の診断：

イメージ名とタグを確認します。イメージ名またはタグのタイプミスが最も一般的な原因です。
イメージがプライベートリポジトリに保存されている場合は、正しいイメージプルシークレットが構成されていることを確認してください。詳細については、「イメージリポジトリに保存されているイメージを使用して ACK ワークロードを作成する」をご参照ください。

CrashLoopBackOff 状態でスタックした Pod

Pod 内のアプリケーションがクラッシュしています。Kubernetes は自動的に再起動しますが、クラッシュが再発します。

問題の診断：

Pod イベントでエラーメッセージを確認します。「Pod イベントの表示」をご参照ください。
Pod ログでアプリケーションのエラーを確認します。「Pod ログの表示」をご参照ください。
ヘルスチェックの構成を確認します。ライブネスプローブ、readiness プローブ、またはスタートアッププローブの構成が正しくないと、Kubernetes が正常なコンテナを強制終了させることがあります。「Pod 構成 (YAML) の表示」をご参照ください。プローブの構成に関する詳細については、「ライブネス、readiness、およびスタートアッププローブの設定」をご参照ください。

Completed 状態でスタックした Pod

Pod 内のすべてのコンテナが起動コマンドの実行を完了し、終了しました。これはバッチジョブでは期待される動作ですが、長時間実行されるサービスでは期待されません。

問題の診断：

Pod 構成で起動コマンドを確認します。コンテナが意図したコマンドをエラーなしで完了した可能性があります。「Pod 構成 (YAML) の表示」をご参照ください。
Pod ログで追加のコンテキストを確認します。「Pod ログの表示」をご参照ください。

Running 状態だが期待どおりに動作しない Pod

Pod は Running ステータスを示していますが、アプリケーションは正しく機能していません。これは多くの場合、Pod の YAML におけるエラーが原因です。

問題の診断：

Pod 構成を期待値と比較します。「Pod 構成 (YAML) の表示」をご参照ください。
環境変数のキーにタイプミスがないか確認します。Kubernetes は、スペルミスのあるフィールド名を警告なしに無視します。その結果、Pod は正常に起動しますが、意図した構成は適用されません。
フィールドレベルのタイプミスを検出するには、デプロイ前に次のコマンドを実行します。
説明
Kubernetes は、スペルミスのあるフィールド名を警告なしに無視します。その結果、Pod は正常に起動しますが、意図した構成は適用されません。
1. 次のコマンドを実行します。
```
   kubectl apply --validate -f <your-file>.yaml
```
  フィールド名が誤って綴られている場合（例： commnd ではなく command）、出力には警告が含まれます：
```
   [<path>] unknown field: commnd
```
2. または、実行中の Pod の YAML をエクスポートし、元のファイルと比較します。
```
   kubectl get pods <pod-name> -o yaml > pod.yaml
```
  エクスポートされた YAML に元のファイルのフィールドが欠落している場合、元のファイルにスペルミスのあるキーが含まれている可能性があります。
Pod ログで実行時エラーを確認します。「Pod ログの表示」をご参照ください。
コンテナターミナルに接続して、ローカルファイルとアプリケーションの状態を検査します。「コンテナターミナルへの接続」をご参照ください。

Terminating 状態でスタックした Pod

Terminating 状態の Pod は削除中ですが、まだ停止していません。この状態の Pod は通常、猶予期間が終了すると自然に解決します。

Pod が長時間 Terminating 状態のままである場合は、強制的に削除します。

kubectl delete pod <pod-name> -n <namespace> --grace-period=0 --force

OOM エラーのトラブルシューティング

コンテナのメモリ使用量が設定されたメモリ制限を超えると、カーネルは Out-of-Memory (OOM) キルでコンテナを終了させます。終了したコンテナは自動的に再起動されることがあります。

症状：

コンテナが予期せず再起動する。
Pod 詳細ページの [イベント] タブに、[pod was OOM killed] というイベントが表示される。

問題の診断：

メモリ使用量のグラフを確認して、スパイクが発生した時期を特定します。「Pod モニタリングの表示」をご参照ください。
高いメモリ使用量がメモリリークによるものか、正当なワークロードの要求によるものかを判断します。
- メモリリーク：メモリスパイクのタイミング、ログエントリ、プロセス名に基づいてアプリケーションコードを調査します。
- 通常のメモリ増加：Pod のメモリ制限を増やします。実際のメモリ使用量が設定された制限の 80% 未満に収まるように制限を設定してください。詳細については、「Pod の管理」をご参照ください。

背景情報については、「コンテナと Pod へのメモリリソースの割り当て」をご参照ください。