1つのPodを移行しようとしたら、別のPodが止まった

「Kubernetes祭り #2」の登壇資料です。
ref: https://3-shake.connpass.com/event/403684/

---

1つのPodを移行しようとしたところ、対象外のPodまで再作成され、起動できなくなりました。
原因はStatefulSetの自動更新と、特定Nodeに紐づくPVの配置制約の衝突です。
本セッションでは、変更が別のPodへ波及した理由と復旧方法、残りのPodを安全に移行した手順を紹介します。
Kubernetesの本番運用で、変更の影響範囲を見極めるための考え方を共有します。

Transcript

1. 1つの Pod を移行しようとしたら、 別の Pod が止まった Kubernetes祭り #2 - (2026 / 09 / 16) © PLAID, Inc.
2. 自己紹介 岡本泰典 (Taisuke Okamoto) a.k.a BigBaBy (@taisuke_bigbaby) KARTE AI Transformation(Dept) Core Platform(Dept) • • • • 開発者体験向上のための万屋 最近は「mila」という OLAP DB を開発してます CloudNative Days というカンファレンスの Chair #〆のラーメンまである倶楽部 メンバー © PLAID, Inc. Inc 2
3. 会社概要 ｜ © PLAID, Inc. 3
4. Webサイト/アプリの訪問者の行動を 顧客ごとにリアルタイムに解析 CX(顧客体験 )プラットフォーム 一人一人に合わせた 顧客体験を提供 ｜ © PLAID, Inc. 44
5. CX Platform KARTE 累計ユーザー数 ※1 年間解析流通⾦額 ※2 199億UU 2.59兆円 秒間トラッキング数 ※3 解析速度 0.x 秒/解析 ⽉間解析データ量 134,000over 180over ペタバイト サイトやアプリの訪問顧客のリアルタイム解析‧セグメンテーションを⾏い、そ れに応じたアクションやコミュニケーションを実 現するためのクラウド上のソフ トウェア ※1 ローンチ〜2023年2⽉までのユニークユーザー数の実績 ｜ © PLAID, Inc. ※2 EC領域における解析流通⾦額。2022年3⽉〜2023年2⽉までの単年の実績 ※3 閲覧、クリック、購⼊などKARTEで計測しているユーザーの全イベントが対象。ローンチ〜2023年3⽉までにおける最⼤値 55
6. なぜ Pod を移行することになったのか？ © PLAID, Inc. 6
7. mila ってなぁに？？ 以下に特化した分散 OLAP DB • • • 人の行動 短・中期間 (数年) インタラクティブ分析 GKE上で動作し、 以下のようなケースが得意 • • • ユーザ軸 / 時間軸での集約 ファネル分析関数 ユーザ属性の扱い © PLAID, Inc. (鋭意開発中...!!!)
8. mila のクエリ処理 Broker がクエリを振り分け、Historical が担当データを検索・集計する © PLAID, Inc.
9. Historical のローカルキャッシュ 以前まで、Historical は GCS 上のデータを Local SSD へキャッシュする Pod を再作成 → キャッシュが消える → Warm Up に時間がかかる © PLAID, Inc.
10. emptyDir から TopoLVM PVC へ Pod を再作成してもキャッシュを再利用できるよう、Historical の保存先を PVC へ変更した © PLAID, Inc.
11. Local SSDの用途変更で Boot Diskが逼迫 Local SSD を TopoLVM PV に使用した結果、Node の一時領域がBoot Disk の領域のみに縮小 Kubernetes における一時領域 = emptyDir + 書き込みレイヤ + ログ + イメージ kubelet が nodefs の空きを監視し、閾値を切ると DiskPressure → eviction © PLAID, Inc.
12. Historical Pod の NodePool 移行 TopoLVM の PV は、作成された Node から自動では移動しない NodePool に PV を作り直し、Pod を1つずつ移行する © PLAID, Inc.
13. 1つずつ移行するはずが、別の Pod まで止まった © PLAID, Inc. 13
14. 最初に試した移行 移行対象の新しい PVC を v2 へ作るため、Historical の affinity に条件を追加した © PLAID, Inc.
15. 作業対象ではない Podまで再作成された StatefulSet の共通設定を変えてしまったため、RollingUpdate が始まった © PLAID, Inc.
16. Pod と PV の配置条件が衝突 Pod と PV の配置条件が衝突、 Pod は Pending の状態のままに © PLAID, Inc.
17. どうやって 1つずつ移行し直したのか © PLAID, Inc. 17
18. 自動更新を避け、 1つずつ手動で移行 Pod template を変更せず、確認しながら1つずつ移行した (最善ではないけど...) © PLAID, Inc.
19. StatefulSet のアップデート戦略 Pod template を変更したとき、既存 Pod をどう更新するかを決める • • RollingUpdate（デフォルト） ◦ Pod を順番に自動更新する ◦ partition で更新範囲を制限できる OnDelete（← 今回使いたかった ） ◦ • 手動で削除した Pod だけを、新しい Pod template で再作成する Recreate（v1.37 の時点で Alpha ） ◦ すべての Pod を停止してから、新しい Pod template で再作成する ※ デフォルト無効。利用には feature gate が必要 ref: https://kubernetes.io/ja/docs/concepts/workloads/controllers/statefulset/ © PLAID, Inc.
20. OnDelete を指定したのに、 StatefulSet へ反映されなかった 理由は単純、Operator 側で updateStrategy のフィールドが固定値のままだった Operator で updateStrategy を引き継ぐよう修正 © PLAID, Inc.
21. まとめ © PLAID, Inc. 21
22. OperatorでStatefulSetを管理するときの教訓 教訓: 設定からPodとPVまで、変更の影響をきちんと追う • Pod template を変える前に、updateStrategy と再作成対象を確認する • Pod の affinity と PV の node affinity をセットで確認する • Operator への指定と生成結果の一致を、reconcile 後までテストする Operator に対して書いた設定だけでなく、 生成されたStatefulSetと、その先で再作成されるPodまで確認する © PLAID, Inc.