GKE アップグレード前に知っておきたい Blue/Green と PDB の関係

Transcript

1. GKE アップグレード前に知っておきたい Blue/Green と PDB の関係 株式会社スリーシェイク Sreake事業部 髙木 創太 Kubernetes Novice Tokyo #41 2026-08-27 Copyright © 3-shake, Inc. All Rights Reserved. 1
2. 自己紹介 • • • Copyright © 3-shake, Inc. All Rights Reserved. 名前 ◦ 髙木 創太 所属 ◦ 株式会社スリーシェイク SRE 一言 ◦ 全てこのアフロでプロフィール画像を統一していま す。よろしくお願いします。 ▪ X: https://x.com/stkk_12 ▪ Zenn: https://zenn.dev/stkk 2
3. 目次 • Blue/Green アップグレードについて ◦ Blue/Green グレードの概要 ◦ Blue/Green グレードの 5 フェーズ • cordon と drain について • PodDisruptionBudget（PDB）について ◦ • 設定値による Pod の挙動比較 まとめ Copyright © 3-shake, Inc. All Rights Reserved. 3
4. 今日話すこと / 話さないこと 話すこと 話さないこと • Blue/Green アップグレードの流れ • cordon と drain が Pod に何をしているか • PodDisruptionBudget（PDB） について 実施環境 • GKE Standard（1.33 → 1.34） ◦ • Surge upgrade の詳細 ◦ 選び方の比較だけ次のスライドで触れます • Cluster Autoscaler との相互作用 • アプリ側のシャットダウン実装 • 自動アップグレード • アップグレードすべきタイミング • その他アップグレードで気にするべきこと コントロールプレーンは事前に更新済み Copyright © 3-shake, Inc. All Rights Reserved. 4
5. 01 Blue/Green アップデートについて Copyright © 3-shake, Inc. All Rights Reserved. 5
6. Blue/Green アップグレードとは Node Pool のノードを、新バージョンのノード群と丸ごと入れ替える 方式です。 • Green（新）を全台作ってから、Blue（旧）を空にする • 一時的にノードがほぼ 2 倍になる # 戦略は Node Pool 単位で設定する $ gcloud container node-pools update POOL \ --cluster=CLUSTER \ --enable-blue-green-upgrade \ ◦ CPU / IP アドレス / ディスクのクォータを先に確認する • Blue を削除するまでは rollback できる • 同一 Node Pool 内での入れ替え --standard-rollout-policy=\ batch-node-count=1,\ batch-soak-duration=60s \ --node-pool-soak-duration=1h 既定は Surge upgrade です。Blue/Green は明示的に選ぶ必要があります。 Copyright © 3-shake, Inc. All Rights Reserved. 7
7. Blue/Green を選ぶべき場面 観点 Surge upgrade（既定） Blue/Green upgrade 進め方 既存ノードを少しずつ作り替える 新ノード群を作ってから旧を空にする 一時的なノード数 ＋ max-surge 分だけ ほぼ 2 倍（Blue と Green が併存） 切り戻し 進んだ分は戻しにくい Blue 削除前なら rollback できる 所要時間 短い 長い（soak を含む） 選ぶとき 選ばないとき • 一時的な費用の増加が許容される場合 • クォータやリソースに 2 倍の余裕がない場合 • ワークロードで中断を許容できない場合 • アップグレードの速度を最適化したい場合 • soak 中に監視して、問題があれば戻したい場合 • ワークロードの中断が許容される場合 • 新しいノードの作成を最小限に抑えてコストを抑える場合 Copyright © 3-shake, Inc. All Rights Reserved. 8
8. Blue/Green の 5 フェーズ ここから不可逆 → ① ② ③ ④ ⑤ Green 作成 Blue cordon Blue drain soak Blue 削除 ← rollback 可能 • ① Green 作成 — cordon より前に全台作られる。ノード数は Blue と同じ • ② Blue を cordon — 以降に生まれる Pod は Green へ • ③ Blue を drain — Pod を退避する • ④ soak — 全 drain 後の待機。既定 は1 時間で、それより前に終えることも可能 • ⑤ Blue 削除 — ここから戻せない 今日は、この 5 フェーズのうち ② cordon と ③ drain の 2 フェーズにフォーカスします。 Copyright © 3-shake, Inc. All Rights Reserved. 9
9. 02 cordon と drain について Copyright © 3-shake, Inc. All Rights Reserved. 9
10. cordon とは 「新規の Pod を配置できない（SchedulingDisabled）」状態にする操 $ kubectl get nodes 作です。 • 既存 Pod はそのまま稼働し、追い出しはしない • Blue/Green ではプール内の全ノードが一括で cordon される ◦ 以降に生まれる Pod は Green にしか乗らない ◦ ノードは 2 倍あるのに、みえる置き場所は Green だけ NAME STATUS node-a Ready,SchedulingDisabled node-b Ready cordon は「置かせない」だけで、追い出しはしない。 Copyright © 3-shake, Inc. All Rights Reserved. 11
11. drain とは ノード上の Pod を退避させて、ノードを空にする操作です。 $ kubectl drain node-a --ignore-daemonsets • Pod の削除に Eviction API を使う • Eviction API は PDB を見て 200 か 429 を返す • Pod は別ノードに再スケジュールされる • 以下にて進行を制御できる ◦ evicting pod default/api-2 # 内部で呼んでいるもの POST /api/v1/namespaces/NS/pods/NAME/eviction バッチでドレインするノードの絶対数。 # PDB に余裕がなければ HTTP/1.1 429 Too Many Requests BATCH_PERCENT ▪ ◦ evicting pod default/api-1 BATCH_NODE_COUNT ▪ ◦ node/node-a already cordoned バッチでドレインするノードの割合 BATCH_SOAK_DURATION ▪ 各バッチがドレインされるまでの時間 「同時に何個落としていいか」を決めているのが PodDisruptionBudget です。 Copyright © 3-shake, Inc. All Rights Reserved. 12
12. 03 PodDisruptionBudget（PDB） について Copyright © 3-shake, Inc. All Rights Reserved. 12
13. PodDisruptionBudget（PDB） とは 「同時に落としていい Pod の数」を宣言するオブジェクトです。 apiVersion: policy/v1 • Eviction API がこれを見て 200 か 429 を返す kind: PodDisruptionBudget • 見るのは kubectl get pdb の ALLOWED DISRUPTIONS spec: maxUnavailable: 1 ◦ 0 の間は 429 で拒否され、drain は待つ selector: matchLabels: app: "api" 主な設定値 フィールド 意味 値の例 minAvailable 最低これだけ Ready を保つ 2 ／ 50%（必要数は切り上げ） maxUnavailable 同時に欠けてよい上限 1 ／ 25% selector 誰を守るか（両方の指定は不可） matchLabels: app=api unhealthyPodEvictionPolicy Ready でない Pod の扱い IfHealthyBudget（既定）／ AlwaysAllow minAvailable と maxUnavailable は同時に指定できません。次の 3 枚で、この設定を変えると何が変わるかをみていきます。 Copyright © 3-shake, Inc. All Rights Reserved. 14
14. パターンA：PDB なし 前提： replicas: 3 ／ Blue 3 ノード → Green 3 ノード ／ Pod は 1 ノードに 1 つ PDB ： なし Blue（旧ノード・cordon 済み） Green（新ノード） P1 P2 P3 P1' P2' P3' node-a node-b node-c node-x node-y node-z 3 つが立て続けに Terminating • PDB が設定されていないため、drain を誰も止めない • drain は代替 Pod（P1'） が Ready になるのを待たない ◦ • どれもまだ Ready ではない 薄い ＝ Terminating 破線 ＝ 起動中（まだ Ready でない） 青枠 ＝ Ready node-a の次に node-b、次に node-c と進行してしまう Ready な Pod が 0 になる瞬間ができる可能性がある Copyright © 3-shake, Inc. All Rights Reserved. # PDB がないので待つ理由がない Eviction(P1) 200 / Eviction(P2) 200 / ... 15
15. パターン B：maxUnavailable: 1 前提： replicas: 3 ／ Blue 3 ノード → Green 3 ノード ／ Pod は 1 ノードに 1 つ PDB ： maxUnavailable: 1 Blue（旧ノード・cordon 済み） Green（新ノード） P1 P2 P3 P1' node-a node-b node-c node-x 欠けているのは 1 つだけ • maxUnavailable 1 により、同時に退避できるのは 1 つ • P1' が Ready になるまで次の drain は進行しない • → 常に Pod 2 つを Ready に保つことが可能 node-y node-z P1' が Ready になるまで次は進まない Eviction(P1) -> 200 OK -> P1 Terminating -> P1' を Green に置く -> pull -> 起動 -> Ready -> allowed が 1 に回復 -> Eviction(P2) …… 以下ループ Copyright © 3-shake, Inc. All Rights Reserved. 16
16. パターン C：minAvailable: 3（replicas と同数） 前提： replicas: 3 ／ Blue 3 ノード → Green 3 ノード ／ Pod は 1 ノードに 1 つ PDB ： minAvailable: 3 Blue（旧ノード・cordon 済み） Green（新ノード） P1 P2 P3 node-a node-b node-c node-x 1 つも薄くならない ＝ Pod が消えない 「Pod が Terminating にならない」 node-y node-z 空のまま ＝ 代替 Pod が作られない $ kubectl get pdb NAME MIN AVAILABLE • minAvailable が replicas と同じ ＝ 1 つも落とせない ALLOWED DISRUPTIONS • minAvailable: 100% / maxUnavailable: 0 も同じ結果 service-a 10 MAX UNAVAILABLE AGE N/A 5 4y143d kubectl get pdb で事前に ALLOWED DISRUPTIONS の確認推奨 HPA で台数が減ったときも、そのタイミングだけ同じことが起きます。 Copyright © 3-shake, Inc. All Rights Reserved. 17
17. PDB の勘所 設定の選び方 • • maxUnavailable を使う ◦ 最低稼働 Pod 数が決まっていない ◦ minAvailable は replicas が減ると厳しくなる ◦ maxUnavailable は減っても 0 にならない 事前に見るもの • ALLOWED DISRUPTIONS が 0 のもの • HPA の minReplicas と PDB の必要数 ◦ 同じなら、その時間帯だけ allowed が 0 になる パーセント指定を活用する ◦ HPA で Pod 数が変動する場合に有効 Copyright © 3-shake, Inc. All Rights Reserved. 18
18. 05 まとめ Copyright © 3-shake, Inc. All Rights Reserved. 18
19. まとめ ① PDB の設定が、Pod の動き方を決める なし＝一斉に落ちる／maxUnavailable: 1＝1 つずつ／replicas と同数＝止まる ② みるのは ALLOWED DISRUPTIONS 0 のもの、そして HPA の下限で 0 になるものを探す $ kubectl get pdb -A # ALLOWED DISRUPTIONS が 0 のものを探す $ kubectl get hpa -A # minReplicas と PDB の必要数が同じものを探す Copyright © 3-shake, Inc. All Rights Reserved. 21
20. ご清聴ありがとうございました！ Copyright © 3-shake, Inc. All Rights Reserved. 20