Terminating:原因と解決策

冒頭まとめ Terminating は、Podの phase ではありません。削除要求を受け、.metadata.deletionTimestamp が入ったPodを kubectl が一覧で示す表示です。 NAME READY STATUS RESTARTS AGE app-7d8f767544-pk4ch 1/1 Terminating 0 3d 削除要求がAPI Serverに受理されても、Podはすぐには消えません。Kubernetes公式のPod終了処理では、既定で30秒の猶予期間が設けられ、その間に preStop、終了シグナル、接続の退避、コンテナ停止などが進みます。finalizerがある場合は、そのfinalizerを管理するコントローラーの後処理が終わるまで、API上のオブジェクトも残ります。 したがって、数十秒の Terminating は異常とは限りません。長時間変わらない場合は、次の4つを分けて確認します。 猶予期間中の正常な終了処理なのか。 preStop またはアプリケーションの終了処理が完了しないのか。 finalizerを管理するコントローラーが後処理を完了できないのか。 配置先ノードまたはkubeletと通信できず、停止を確認できないのか。 ここで最も重要な事実訂正があります。 kubectl delete pod <Pod名> -n <名前空間> --grace-period=0 --force この強制削除は、ノード上のプロセスを確実に停止してからPodを消す操作ではありません。kubectl delete の公式リファレンスは、API Serverがkubeletによる終了確認を待たず、同じ識別情報を持つ処理が別のマシンで動き続け、データの不整合や損失につながる可能性を警告しています。 強制削除は一覧をきれいにする操作ではありません。古い処理が停止済み、または二度と共有資源へ接続できないと確認した後に限る、最後の手段です。 エラーの概要 Podを通常削除すると、API Serverはオブジェクトへ削除時刻と猶予期間を記録します。 metadata: deletionTimestamp: "2026-08-05T03:12:44Z" deletionGracePeriodSeconds: 30 この時点で削除要求は失敗していません。finalizerの公式説明によれば、finalizerを持つオブジェクトへの削除要求は 202 Accepted で受理され、.metadata.deletionTimestamp が設定されます。その後、必要な後処理が済み、finalizerの一覧が空になると削除が完了します。 Terminating は、この途中経過を kubectl が表示したものです。API上のPodの status.phase は、終了処理中も Running や Pending のままの場合があります。 kubectl get pod <Pod名> -n <名前空間> \ -o jsonpath='{.status.phase}{"\t"}{.metadata.deletionTimestamp}{"\t"}{.metadata.finalizers}{"\n"}' Running 2026-08-05T03:12:44Z [batch.kubernetes.io/job-tracking] もう1つ混同しやすいのが、次の3種類の時間です。 ...

2026年8月5日 · ErrorLog