Container Compute Service:Troubleshoot pod issues

このトピックの内容

診断プロセス

1. Pod の異常状態を確認します。詳細については、「Pod のステータス確認」をご参照ください。

   1. Pod が異常状態にある場合は、そのイベント、ログ、設定を確認して原因を特定します。詳細については、「一般的なトラブルシューティング方法」をご参照ください。Pod の異常状態とその対処法については、「一般的な Pod の異常状態と解決策」をご参照ください。

   2. Pod が Running 状態であるにもかかわらず期待どおりに動作しない場合は、「Running 状態の Pod が動作しない場合」をご参照ください。

2. Pod の OOM (Out of Memory) 問題が確認された場合は、「Pod の OOM 問題のトラブルシューティング」をご参照ください。

3. 問題が解決しない場合は、チケットを送信してください。

一般的な Pod の異常状態と解決策

一般的なトラブルシューティング方法

Pod のステータス確認

1. ACS コンソール にログインします。左側のナビゲーションペインで、クラスター をクリックします。

2. クラスター ページで、管理するクラスターを見つけ、その ID をクリックします。クラスター詳細ページの左側のナビゲーションペインで、ワークロード > ポッド を選択します。

3. ポッド ページの左上で、Pod の 名前空間 を選択し、そのステータスを確認します。

   • ステータスが Running の場合、Pod は期待どおりに動作しています。

   • ステータスが Running でない場合、Pod は異常状態です。解決策については、「一般的な Pod の異常状態と解決策」をご参照ください。

Pod の詳細確認

Pod の設定確認

Pod のイベント確認

1. ACS コンソール にログインします。左側のナビゲーションペインで、クラスター をクリックします。

2. クラスター ページで、管理するクラスターを見つけ、その ID をクリックします。クラスター詳細ページの左側のナビゲーションペインで、ワークロード > ポッド を選択します。

3. ポッド ページの左上で、Pod の 名前空間 を選択します。次に、対象 Pod の名前をクリックするか、[操作] 列の [Details] をクリックします。

4. Pod の詳細ページの右上隅にある編集をクリックすると、Pod の YAML ファイルと詳細設定を表示できます。

5. Pod の詳細ページで、イベント タブをクリックします。

   説明

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

Pod のログ確認

1. ACS コンソール にログインします。左側のナビゲーションペインで、クラスター をクリックします。

2. クラスター ページで、管理するクラスターを見つけ、その ID をクリックします。クラスター詳細ページの左側のナビゲーションペインで、ワークロード > ポッド を選択します。

3. ポッド ページの左上で、Pod の 名前空間 を選択します。次に、対象 Pod の名前をクリックするか、[操作] 列の [Details] をクリックします。

4. Pod の詳細ページで、ログ タブをクリックします。

   説明

   Alibaba Cloud Container Service for Kubernetes (ACK) クラスターは Simple Log Service と統合されています。クラスター作成時に Simple Log Service を有効にすると、標準出力やコンテナ内のテキストファイルを含むコンテナログを収集できます。詳細については、「Pod の環境変数を使用したアプリケーションログ収集の設定」をご参照ください。

Pod のモニタリングデータ確認

1. ACS コンソール にログインします。左側のナビゲーションペインで、クラスター をクリックします。

2. クラスター ページで、管理するクラスターを見つけ、その ID をクリックします。クラスター詳細ページの左側のナビゲーションペインで、ワークロード > Prometheus モニタリングPrometheus モニタリング を選択します。

3. Prometheus 監視 ページで、クラスターの概要 タブをクリックして、Pod の CPU、メモリ、ネットワーク I/O のモニタリングダッシュボードを表示します。

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

1. ACS コンソール にログインします。左側のナビゲーションペインで、クラスター をクリックします。

2. クラスター ページで、管理するクラスターを見つけ、その ID をクリックします。クラスター詳細ページの左側のナビゲーションペインで、ワークロード > ポッド を選択します。

3. ポッド ページで、対象の Pod を見つけ、アクション 列の 端末 をクリックします。

   説明

   ターミナルを使用して、コンテナ内のローカルファイルやその他の情報を確認します。

Pod の障害診断

1. ACS コンソール にログインします。左側のナビゲーションペインで、クラスター をクリックします。

2. クラスター ページで、管理するクラスターを見つけ、その ID をクリックします。クラスター詳細ページの左側のナビゲーションペインで、ワークロード > ポッド を選択します。

3. ポッド ページの左上で、Pod の 名前空間 を選択します。次に、対象 Pod の名前をクリックするか、[操作] 列の [Details] をクリックします。

4. ポッド ページで、対象の Pod を見つけ、アクション 列の 診断 をクリックします。

   説明

   Pod の診断を実行し、結果に基づいて問題を解決します。詳細については、「クラスター診断の使用」をご参照ください。

Pod が Pending 状態の場合

原因

Pending 状態の Pod は、通常、リソースの依存関係やクォータの設定ミスが原因でスケジュールできません。

症状

Pod のステータスが Pending です。

解決策

Pod のイベントを調べて、Pod をスケジュールできない理由を特定します。主な原因は次のとおりです：

• リソースの依存関係

  Pod は、ConfigMap や PersistentVolumeClaim (PVC) などの他のクラスターリソースに依存する場合があります。たとえば、PersistentVolumeClaim (PVC) は、Pod で使用される前に永続ボリュームにバインドされる必要があります。

• クォータの設定ミス

  イベントと監査ログを確認します。

Pod のステータスが Init:N/M、Init:Error、または Init:CrashLoopBackOff の場合

原因

• Pod が Init:N/M 状態のままの場合、M 個の Init コンテナがありますが、正常に起動したのは N 個のみで、残りの M-N 個のコンテナは起動に失敗しています。

• Pod が Init:Error 状態の場合、Pod 内の Init コンテナが起動に失敗しています。

• Pod が Init:CrashLoopBackOff 状態の場合、Init コンテナが起動に失敗し、再起動を繰り返しています。

症状

• Pod のステータスが Init:N/M です。

• Pod のステータスが Init:Error です。

• Pod のステータスが Init:CrashLoopBackOff です。

解決策

1. Pod のイベントを確認して、まだ起動していない Init コンテナに問題がないかを確認します。詳細については、「Pod のイベント確認」をご参照ください。

2. まだ起動していない Init コンテナのログを確認して、問題をトラブルシューティングします。詳細については、「Pod のログ確認」をご参照ください。

3. Pod の設定を確認して、まだ起動していない Init コンテナの設定が正しいことを確認します。詳細については、「Pod の設定確認」をご参照ください。Init コンテナの詳細については、「Init コンテナのデバッグ」をご参照ください。

Pod が ImagePullBackOff 状態の場合

原因

ImagePullBackOff 状態の Pod は、スケジュールされましたが、コンテナイメージのプルに失敗しています。

症状

Pod のステータスが ImagePullBackOff です。

解決策

Pod のイベント説明を確認して、プルに失敗したイメージの名前を特定します。

1. コンテナイメージ名が正しいことを確認します。

2. プライベートイメージリポジトリを使用している場合は、「イメージリポジトリのイメージを使用して ACK ワークロードを作成する」の解決策をご参照ください。

Pod が CrashLoopBackOff 状態の場合

原因

CrashLoopBackOff 状態は、コンテナ内のアプリケーションに問題があることを示しています。

症状

Pod のステータスが CrashLoopBackOff です。

解決策

1. Pod のイベントを確認して、Pod に問題がないかを確認します。詳細については、「Pod のイベント確認」をご参照ください。

2. Pod のログを確認して、問題をトラブルシューティングします。詳細については、「Pod のログ確認」をご参照ください。

3. Pod の設定を確認して、コンテナのヘルスチェック設定が正しいことを確認します。詳細については、「Pod の設定確認」をご参照ください。Pod のヘルスチェックの詳細については、「Liveness Probe、Readiness Probe、Startup Probe の設定」をご参照ください。

Pod が Completed 状態の場合

原因

Pod は、すべてのコンテナプロセスが終了した後に Completed 状態になります。

症状

Pod のステータスが Completed です。

解決策

1. Pod の設定を確認して、Pod 内のコンテナの起動コマンドを特定します。詳細については、「Pod の設定確認」をご参照ください。

2. Pod のログを確認して、問題をトラブルシューティングします。詳細については、「Pod のログ確認」をご参照ください。

Running 状態の Pod が動作しない場合

原因

デプロイメントに使用される YAML ファイルにエラーが含まれています。

症状

Pod は Running 状態ですが、期待どおりに動作しません。

解決策

1. Pod の設定を確認して、コンテナの設定が期待どおりであるかを確認します。詳細については、「Pod の設定確認」をご参照ください。

2. 次の方法を使用して、環境変数のキーにスペルミスがないかを確認します。

   次の例は、command が commnd と誤って入力された場合にスペルミスを特定する方法を示しています。

   説明

   Pod の作成時、クラスターは Pod 仕様のフィールドにあるスペルミスを無視する場合があります。たとえば、Command を Commnd と誤って入力した場合でも、その YAML ファイルを使用してリソースを作成できます。ただし、ランタイム時にコンテナはスペルミスのコマンドを無視し、代わりにイメージのデフォルトコマンドを実行します。

   1. kubectl apply -f コマンドを実行する前に、--validate を含めて、kubectl apply --validate -f XXX.yaml コマンドを実行します。

      command を commnd と誤って入力した場合、XXX] unknown field: commnd XXX] this may be a false alarm, see https://gXXXb.XXX/6842pods/test というエラーメッセージが表示されます。

   2. 次のコマンドを実行し、出力された pod.yaml ファイルを、ポッドの作成に使用した元のファイルと比較します。

        kubectl get pods [$Pod] -o yaml > pod.yaml

      説明

      [$Pod] は異常な Pod の名前です。kubectl get pods コマンドを実行して Pod 名を表示できます。

      • pod.yaml ファイルが Pod の作成に使用したファイルよりも数行多い場合、作成された Pod が期待どおりであることを示します。

      • 元のファイルの一行が pod.yaml ファイルにない場合、元のファイルにスペルミスがあることを示します。

3. Pod のログを確認して、問題をトラブルシューティングします。詳細については、「Pod のログ確認」をご参照ください。

4. ターミナル経由でコンテナにアクセスし、内部のローカルファイルが期待どおりであるかを確認します。詳細については、「ターミナル経viaでのコンテナへの接続」をご参照ください。

Pod が Terminating 状態の場合

原因

Pod はシャットダウン処理中です。

症状

Pod のステータスが Terminating です。

解決策

Terminating 状態の Pod は、猶予期間の後に自動的に削除されます。Pod が Terminating 状態のまま動かなくなった場合は、次のコマンドを実行して強制的に削除します：

kubectl delete pod [$Pod] -n [$namespace] --grace-period=0 --force

Pod の OOM 問題のトラブルシューティング

原因

コンテナがメモリ制限を超えると、システムは OOM (Out of Memory) イベントでコンテナを終了させ、予期しない終了を引き起こします。OOM イベントの詳細については、「コンテナと Pod へのメモリリソースの割り当て」をご参照ください。

症状

• 終了したプロセスがブロッキングプロセスである場合、コンテナが予期せず再起動することがあります。

• OOM 問題が発生すると、コンソールの Pod 詳細ページの イベント タブに OOM イベント pod was OOM killed が表示されます。

解決策

1. Pod のモニタリングデータでメモリ使用量の増加を確認し、問題がいつ発生したかを特定します。詳細については、「Pod のモニタリングデータ確認」をご参照ください。

2. モニタリングデータ、メモリ使用量の推移、ログ、プロセス名に基づいて、対応するプロセスにメモリリークがあるかどうかを確認します。

   • OOM の原因がプロセスのメモリリークである場合は、アプリケーションに基づいて根本原因をトラブルシューティングします。

   • プロセスが正常に実行されている場合は、ワークロードのニーズに基づいて Pod のメモリ制限を増やします。Pod の実際のメモリ使用量がメモリ制限の 80% を超えないようにすることを推奨します。詳細については、「Pod の管理」をご参照ください。