Kubernetes Exit Code 143とは?8つの原因と解決策

Kubernetes Exit Code 143のトラブルシューティング方法

Exit Code 143のトラブルシューティングとは、誰がSIGTERMを送ったのか、そしてなぜ送ったのかを突き止めることです。Kubernetesは通常のワークロード管理でこのシグナルを頻繁に使用するため、Exit Codeだけでは障害とは判断できません。

まずPodとコンテナのステータスを確認し、次に終了時刻をログ、イベント、ロールアウト、スケーリング活動、ノード操作と関連付けます。また、アプリケーションがSIGTERM受信時に正しく応答するかも確認しましょう。

ステップ1:Podのステータスを確認する

まず、Podの現在の状態と詳細なステータスを確認します:

kubectl get pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace>

コンテナの再起動、Podの状態(Conditions)、直近のイベント、終了に関する情報を確認します。kubectl describe podでは、プローブの失敗、エビクション、スケジューリングの変更など、シャットダウンに関連するその他のイベントも確認できます。

PodがDeployment、StatefulSet、その他のコントローラーによって管理されている場合は、そのオーナーも特定しましょう。終了が通常のコントローラー動作の一部だったかどうかの判断に役立ちます。

ステップ2:コンテナのExit Codeと終了理由を確認する

コンテナの現在および直前の終了状態を確認します。再起動したコンテナについては、KubernetesがExit Code、理由、シグナル、タイムスタンプなどの詳細を保持していることがあります:

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.status.containerStatuses[*].lastState.terminated}'

記録されたExit Codeが143であることを確認します。あわせて終了理由と、startedAtおよびfinishedAtのタイムスタンプも確認しましょう。これらはKubernetesイベントやアプリケーションログと突き合わせることができます。

Exit Code 143そのものが原因を説明していると考えないでください。これは、プロセスがSIGTERMによって終了したことを示すだけで、どのKubernetes操作や外部プロセスが終了を開始したのかまでは分かりません。

ステップ3:現在および直前のコンテナログを確認する

終了時刻前後のアプリケーションログを確認します:

kubectl logs <pod-name> -n <namespace>

コンテナが再起動している場合は、前回のコンテナインスタンスのログを確認します:

kubectl logs <pod-name> -n <namespace> --previous

シャットダウンメッセージ、シグナル受信メッセージ、未完了のリクエスト、接続エラー、アプリケーションの例外を探します。SIGTERMの受信、新規処理の停止、リソースのクローズ、終了という一連の正常な流れが確認できれば、通常はグレースフルな終了を示しています。

複数コンテナのPodでは、-c <container-name>で対象のコンテナを指定します。

ステップ4:Kubernetesイベントを調べる

Kubernetesイベントからは、終了直前に何が起きたのかという文脈を得られます:

kubectl get events -n <namespace> \
  --sort-by=.metadata.creationTimestamp

プローブの失敗、Podのエビクション、コンテナの再起動、スケーリング、スケジューリング、ノードの問題に関するメッセージを探します。イベントのタイムスタンプをコンテナの終了タイムスタンプと比較してください。

イベントは有用ですが、完全な監査証跡ではありません。期限切れで消えることがあり、また、すべてのPod終了原因が、なぜSIGTERMが送られたのかを明確に説明するイベントを生成するとは限りません。

ステップ5:Deploymentとロールアウトの状況を確認する

Deploymentの更新やその他のワークロード変更中にコンテナが停止したのかどうかを確認します:

kubectl rollout status deployment/<deployment-name> -n <namespace>
kubectl rollout history deployment/<deployment-name> -n <namespace>

Deploymentのトラブルシューティングでは、ReplicaSetも確認しましょう。終了時刻の前後に新しいReplicaSetが出現している場合、ロールアウトによって古いPodが置き換えられていた可能性が高いと言えます。

Exit Code 143が新しいアプリケーションバージョンのデプロイ時にのみ発生するのであれば、通常のPod置き換えの一部である可能性が高いです。次に確認すべきは、それらのPodがリクエストを落としたり処理を失ったりすることなく、クリーンにシャットダウンしているかどうかです。

ステップ6:スケーリング、エビクション、ノードイベントを確認する

レプリカの変更、オートスケーリング、ノードのドレイン、インフラ操作が終了のタイミングと一致していないかを確認します。HorizontalPodAutoscalerを使用しているワークロードでは、その現在の状態と直近の挙動を確認します:

kubectl get hpa -n <namespace>
kubectl describe hpa <hpa-name> -n <namespace>

Podが稼働していたノードも確認します:

kubectl describe node <node-name>

ノードのシャットダウン、メンテナンス、リソース圧迫、オートスケーラーの動作、エビクション関連のイベントを探します。無関係な多数のPodがほぼ同時に終了している場合は、アプリケーション固有の問題よりも、ノードレベルまたはクラスターレベルの操作である可能性が高くなります。

ステップ7:アプリケーションがSIGTERMを正しく処理しているかを確認する

最後に、アプリケーションのメインプロセスがSIGTERMにどう応答するかを検証します。通常は、新規処理の受け付けを停止し、アクティブな操作を完了または安全にキャンセルし、必要なデータをフラッシュし、外部接続を閉じて、終了猶予期間が切れる前に終了すべきです。

Podに設定されている猶予期間を確認します:

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.spec.terminationGracePeriodSeconds}'

また、シグナルが実際にアプリケーションに届いているかも確認してください。シェルスクリプトや設定が誤っているプロセスマネージャー経由でアプリケーションを起動しているコンテナでは、アプリケーションがPID 1でない場合にシグナルの転送が妨げられることがあります。

グレースフルシャットダウンが利用可能な期間より常に長くかかる場合は、シャットダウン処理を改善するか、必要に応じてterminationGracePeriodSecondsを増やしましょう。アプリケーションに直接SIGTERMを送ってテストすれば、シグナルハンドラーが実行され、想定時間内に終了することを確認できます。

Kubernetes Exit Code 143を防ぐベストプラクティス {#best-practices-to-prevent-kubernetes-exit-code-143}

ここでは、Kubernetesを運用する際にExit Code 143を防ぐための方法をいくつか紹介します。

1. SIGTERMのグレースフルなハンドリングを実装する

アプリケーションはSIGTERMを明示的に処理し、シグナルが到着したら正常な手順でシャットダウンを開始すべきです。サービスは、新規処理の受け付けを停止し、アクティブなリクエストを完了または安全にキャンセルし、接続を閉じ、バッファされたデータをフラッシュしてから終了します。

アプリケーションが実際にシグナルを受信していることを必ず確認してください。ラッパーのシェルスクリプトやプロセスマネージャーがシグナルを正しく転送しないと、シグナルがアプリケーションに届かないことがあります。エントリーポイントスクリプトでexecを使えば、シェルをアプリケーションプロセスに置き換えられます:

exec /app/my-service

これによりアプリケーションがPID 1となり、コンテナの終了シグナルが直接届くようになります。

2. 適切なterminationGracePeriodSecondsを設定する

アプリケーションが通常のシャットダウン処理を完了できる十分な長さに、terminationGracePeriodSecondsを設定します。Kubernetesのデフォルトは30秒ですが、長時間のリクエスト、バッチジョブ、メッセージコンシューマー、クリーンアップ作業の多いアプリケーションには不十分な場合があります。

例:

spec:
  terminationGracePeriodSeconds: 60

単に大きなタイムアウトを設定するのではなく、実際に観測されたシャットダウン時間に基づいて値を決めてください。不必要に長い猶予期間はロールアウト、スケーリング操作、ノードメンテナンスを遅らせる可能性があるため、アプリケーションは可能な限り速やかに終了すべきです。

3. 追加のシャットダウンロジックが必要な場合はpreStopフックを使用する

preStopフックを使うと、コンテナが通常の停止シグナルを受け取る前に追加のロジックを実行できます。シャットダウンに明示的なコマンド、サービスの登録解除、またはアプリケーションの標準的なSIGTERMハンドラーの外で行う操作が必要な場合に有用です。

例:

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "/app/prepare-shutdown.sh"]

フックは短く、信頼性の高いものに保ちましょう。フックの実行時間はPodの終了猶予期間を消費するため、遅いpreStopフックは、SIGTERM受信後にアプリケーションがシャットダウンに使える時間を減らしてしまいます。

4. バックグラウンドワーカーを安全に停止させる

バックグラウンドワーカーにも、HTTPサービスと同様に終了処理が必要です。ワーカーがSIGTERMを受信したら、通常は新しいジョブの受け付けを停止し、現在のジョブを完了させるか、キューシステムがサポートする仕組みを使って未完了の処理をキューに戻すべきです。

ジョブの処理が途中の状態で即座に終了することは避けてください。ワークロードによっては、処理の喪失、重複処理、不完全なデータベース更新、アプリケーション状態の不整合につながる可能性があります。

長時間実行されるジョブについては、終了猶予期間が想定される処理時間と整合していることを確認してください。期間内に確実に完了できないジョブは、リトライ可能または再開可能になるように設計しましょう。

5. Exit Code 143は状況とあわせて監視する

Exit Code 143が発生するたびにアラートを出さないでください。ローリングデプロイ、Podの手動削除、スケールダウン操作、ノードのドレインなど、日常的なKubernetesの動作では発生が想定されるものです。

その代わりに、Exit Code 143をPodの再起動率、デプロイ活動、Kubernetesイベント、ノード操作、アプリケーションエラー、失敗したリクエストと関連付けて分析します。既知のクラスター操作がないのにSIGTERMによる終了が繰り返される場合は、さらなる調査が必要です。

前後の状況とあわせて監視することで、Exit Code 143は診断シグナルとして有用になります。正常なライフサイクル活動を、プローブの失敗、不安定なワークロード、予期しないプロセス終了、インフラの変更と区別するのに役立ちます。

FAQ

Kubernetes Exit Code 143はエラーですか? 通常はエラーではありません。Exit Code 143は、コンテナのメインプロセスがSIGTERMを受信して停止したことを意味します。Kubernetesはローリングアップデート、Podの削除、スケールダウン、ノードのドレインなどの通常の動作中にこのシグナルを送信するため、このコードだけでは障害とは判断できません。

Exit Code 143とExit Code 137の違いは何ですか? Exit Code 143は128 + 15で、SIGTERM受信後にプロセスが停止したことを意味し、アプリケーションにはグレースフルシャットダウンの機会が与えられます。Exit Code 137は128 + 9で、捕捉できないSIGKILLを意味します。コンテナが終了猶予期間内に終了しなかった場合や、メモリ不足で強制終了された場合に発生します。

KubernetesはSIGKILLを送信するまでどのくらい待ちますか? 終了猶予期間のデフォルトは30秒で、terminationGracePeriodSecondsで設定します。preStopフックも同じ時間枠内で実行されるため、フックの処理が遅いと、アプリケーションがSIGTERMを処理する時間が減ります。

SIGTERMの送信元はどうすれば特定できますか? まずkubectl describe podとコンテナの直前の終了状態を確認し、次にタイムスタンプをKubernetesイベント、ロールアウト履歴、HPAの動作、ノードイベントと比較します。クラスター内に一致するものがなければ、スクリプト、スーパーバイザー、サイドカーもSIGTERMを送信できるため、アプリケーションやプロセスマネージャーのログを確認してください。

Exit Code 143でアラートを出すべきですか? いいえ、すべての発生に対してではありません。既知のロールアウト、スケーリング、ノード操作がないのにSIGTERMによる終了が繰り返される、あるいは失敗したリクエストや再起動率の上昇と重なるといったパターンに対してアラートを出しましょう。

PerfectScaleで、どんな終了処理でもKubernetesワークロードを安定稼働

Exit Code 143は通常、正常なライフサイクル活動の表れですが、ロールアウト、スケールダウン、ノードの変更が頻繁に行われると、日常的な終了と本当のレジリエンス問題を見分けるのが難しくなります。DoiTのPerfectScale for Kubernetesは、安定性を最優先とするアプローチで、ワークロードの特性を踏まえた自動化を提供し、あらゆる最適化推奨の中心にアプリケーションの健全性を据えます。プラットフォームチーム、SREチーム、FinOpsチームは、クラスターの健全性、パフォーマンス、コストを単一のビューで把握できるため、手動での監視や再設定を繰り返すことなく、レジリエンスの問題を発見し、ワークロードを適正化できます。

PerfectScale for Kubernetesの主な機能:

• レジリエンス問題の検出: Podfitはクラスターの健全性とコストをきめ細かく可視化し、注意が必要な領域を優先順位付けして、無駄なリソースやレジリエンスの問題を素早く特定できるよう支援します。
• 安定性を最優先にしたライトサイジング: コンテキストを考慮したライトサイジングが、パフォーマンスのベースライン、トラフィックパターン、ビジネス上の重要度に基づいてアクションを調整するため、最適化がアプリケーションの健全性を犠牲にすることはありません。
• 自律的なワークロード最適化: データドリブンな推奨と自動化ワークフローがワークロードを継続的に適正化し、エンジニアリングの時間を奪う再設定の繰り返しを解消します。
• オートスケーラー設定のインサイト: 実行可能な推奨によりHPAやKEDAの設定を改善でき、InfrafitはKarpenterなどのノードオートスケーラーの効果を最大化します。
• ノード使用率の可視化: Infrafitがアイドル状態のノードキャパシティを特定し、ワークロードに最適なノードを推奨することで、クラスターのパフォーマンスと信頼性を最大限に引き出します。
• コンテナレベルのリソース追跡: CPUとメモリをコンテナレベルで監視し、無駄を排除して実際の使用量に基づいてリソースを設定できます。
• ガードレールとポリシー: ワークロードの重要度と環境タイプに応じた最適化ルールを定義し、本番ワークロードを保護します。
• マルチクラウド・マルチクラスターの可視性: GPU使用率の追跡を含め、クラスター数やクラウドプロバイダーを問わず、データドリブンなインテリジェンス、ポリシー適用、最適化アクションを利用できます。

信頼性が高く、コスト効率に優れたKubernetesワークロードを運用しませんか?PerfectScale for Kubernetesの詳細はこちら。