クラスターの調査とトラブルシューティング

最初のデプロイが、ときどき期待どおりに動かないことがあります。幸い、kubectlには何が起きているかを把握し、手順に沿って修正するために必要な機能がすべてそろっています。

まずは広い範囲から確認します。クラスターの Node は健全で、Ready になっていますか。

Pod のフェーズを確認します。Running は正常です。Pending、CrashLoopBackOff、ImagePullBackOff は、それぞれ特定の問題を示しています。

kubectl describeは最も頼りになるコマンドです。仕様、現在の状態、スケジューリングやイメージ取得の失敗を説明するEventsの一覧を表示します。

アプリケーションのエラーは、通常ログに現れます。-fでログをストリーミング表示するか、クラッシュしたコンテナの直前のログを--previousで読み取ります。

Podが再起動を繰り返している場合、現在のコンテナにはまだ役立つログがない可能性があります。代わりに、直前のインスタンスを表示してください。

実行中のコンテナ内でシェルを開くと、内部からファイル、環境変数、接続性を確認できます。

名前空間全体の最近のイベントを時系列で確認すると、Podごとの表示では見落とすパターンを発見できます。

これは、Kubernetesがイメージを取得できないことを意味します。名前やタグが間違っている、プライベートレジストリの認証情報がない、または入力ミスがある可能性があります。describeで正確な取得エラーを確認できます。

コンテナが起動した後、繰り返し終了しています。クラッシュの原因をlogs --previousで確認してください。多くの場合、コマンドの誤り、設定の不足、依存関係の失敗が原因です。

ライブCPU使用量とメモリ使用量を確認するにはkubectl topを使用します（metrics-serverが必要です）。また、port-forwardを使うと、手元のマシンからServiceを直接テストできます。

再起動を繰り返すPodを診断します。

これでトラブルシューティングのツールキットがそろいました。

• 正常性の確認にはget nodes/pods、イベントの確認にはdescribe
• アプリケーションエラーの確認にはlogs（および--previous）
• 内部からの確認にはexec、テストにはport-forward
• ImagePullBackOffとCrashLoopBackOffを認識する

これらを落ち着いて体系的に確認すれば、通常は問題をすばやく見つけられます。