Tech Learning Daily

Pod 削除は「エンドポイント除去」と「シグナル送信」を同時に走らせる

kubectl delete pod や Deployment のロールアウトで Pod が削除対象になると、API サーバーはその Pod オブジェクトに deletionTimestamp を刻み、Pod は Terminating 状態になる。ここから 2 本の処理が同時に走り始める。1 本目は制御プレーン側の処理で、Pod を Service の EndpointSlice（どの Pod にトラフィックを転送するかを保持する API オブジェクト）から除外し、それを watch している kube-proxy や Ingress コントローラーに変更を伝える。2 本目は Pod が乗っているノードの kubelet の処理で、preStop フック（設定されていれば）を実行したあと、コンテナの PID 1 に SIGTERM を送る。

Kubernetes の公式ドキュメントは、この 2 本の処理の間に順序の保証はないと明記している。エンドポイント除去の通知が kube-proxy や Ingress に届いて実際のルーティングが更新されるより先に、kubelet 側の SIGTERM 送信と後続の停止処理が終わってしまうことがある。つまり「もうトラフィックを流していないはず」の Pod へ、外側からはまだリクエストが飛んでくる時間帯が存在する。

kubectl delete pod 要求
        ▼
 deletionTimestamp 付与
 (Pod は Terminating に)
   ┌──────┴───────┐
   ▼               ▼
制御プレーン        kubelet:
Endpoint除去を      preStop 実行後
kube-proxy/Ingress  SIGTERM 送信
へ伝播 (ラグあり)     │
   │                ▼
   │            猶予内(既定30s)に
   │            終了しなければ
   │            SIGKILL で強制終了
   └────────┬────────┘
        同時並行 = 順序保証なし

SIGTERM を受けてから強制終了までの猶予は、既定 30 秒

kubelet が送る SIGTERM を受け取ったアプリケーションプロセスには、後片付けをして自発的に終了するための猶予期間が与えられる。この長さは Pod の spec.terminationGracePeriodSeconds で決まり、既定値は 30 秒だ。設定しなければ、SIGTERM から 30 秒経ってもプロセスが終了していない場合、kubelet は SIGKILL を送って強制終了させる。SIGKILL はプロセスに後片付けの機会を一切与えないため、処理中だったリクエストのコネクションはその場で切断される。

preStop フックがある場合、それは SIGTERM の前に実行される。ここで注意したいのは、preStop の実行時間は terminationGracePeriodSeconds の 30 秒に上乗せされるのではなく、その 30 秒の予算の中に含まれるという点だ。preStop に 25 秒かかる sleep を書けば、残り 5 秒しかアプリ本体の終了処理に使えない。

伝播のラグが、なぜ数件だけの 502 に直結するのか

この記事の疑問「なぜデプロイのたびに 502 が数件だけ出るのか」に答えると、原因の多くはこのラグの窓に着弾したリクエストだ。EndpointSlice の変更が kube-proxy のルーティングルールや Ingress コントローラー・クラウドのロードバランサーの設定に反映されるまでには、watch 通知の伝達やコントローラー自身の再計算処理を挟むぶん、ゼロではない時間がかかる。この間に来た新規リクエストは、まだ古いルーティング情報に従って、SIGTERM 後・SIGKILL 前の（あるいはすでに消えた）Pod へ送られてしまう。

ここまで読むと「じゃあ伝播が終わるまで待てば解決する」と単純に思うかもしれない。しかし実際にその待ち時間を作るのはアプリでも Kubernetes 本体でもなく、次に説明する preStop フックというワンクッションだ。

定石の対策: preStop で SIGTERM 送信を数秒遅らせる

実務で最もよく使われる対策は、preStop フックに sleep を仕込んで SIGTERM の到達自体を遅らせることだ。

spec:
  terminationGracePeriodSeconds: 45
  containers:
    - name: app
      lifecycle:
        preStop:
          exec:
            command: ["sh", "-c", "sleep 5"]

sleep 5 を挟むと、Pod が Terminating になってから実際に SIGTERM が届くまで 5 秒の猶予ができ、その間にエンドポイント除去がクラスタ内に伝播する時間を稼げる。同時に terminationGracePeriodSeconds を既定の 30 秒より長い 45 秒に伸ばしているのは、preStop の 5 秒とアプリ本体の終了処理の時間を合わせても 30 秒に収まらない場合、SIGKILL が先に発動してしまうのを避けるためだ。伸ばさずに sleep だけ足すと、preStop の待ち時間がそのままアプリの終了処理時間を圧迫する。

ただし sleep が効くのは、待っている間もアプリがリクエストを普通に受け付け続けている場合に限る。SIGTERM を受けた瞬間にリスニングソケットを閉じる実装になっていると、preStop の sleep 中であってもその Pod への新規リクエストはやはり失敗する。preStop はあくまで「除去の伝播を待つための時間稼ぎ」であって、アプリ側のシグナルハンドリングを代替するものではない。