Spot 节点被抢占回收时，terminationGracePeriodSeconds 与 PDB 到底哪个先生效？drain 窗口能不能被 PDB 拉长？

苏星河-683 征集中

KubernetesSpot实例PDBterminationGracePeriodSeconds优雅退出SRE云原生

背景我维护一个 20 节点（16C64G，K8s 1.28.9，containerd 1.7.13，cgroup v2）生产集群，其中 60% 节点是 Spot 抢占式实例（阿里云，按量+抢占混合池），核心服务是 Java 17 无状态 API（12 副本，JIT + 本地 Caffeine 缓存，drain 耗时 P99 约 40s，terminationGracePeriodSeconds 配了 90s），Deployment 里配了 PDB minAvailable=10。

现象过去两个月 oncall 复盘了 4 次 Spot 回收事件，观察到两个让我困惑的点：

有 2 次回收发生在业务高峰期，被抢占节点上的 Pod 从收到 SIGTERM 到容器被 kill 只用了约 30s，远短于我配的 90s grace period——但同样的 90s 在主动 kubectl drain 时是完整走完的；
另有 1 次回收，节点上该服务有 4 个 Pod（超过 PDB 允许的 maxUnavailable=2），kubelet 开始驱逐后 PDB 似乎没有拦住「超出部分」，最终该服务瞬时副本数掉到 8，触发了下游熔断。

已尝试的排查与结果

查了 node.kubernetes.io/unschedulable 事件时间线：Spot 回收时云厂商先给节点打 cordoned，然后下发 deleteNode 请求，kubelet 走的是 evict 接口（日志里能看到 eviction 关键字），但 evict 请求里的 metadata.resourceVersion 和 PDB 校验结果我目前没拿到（kubelet 日志 level 不够）；
翻了阿里云文档，只说「Spot 实例回收前会给 5 分钟通知（通过 IMDS 和系统事件）」，但没说 drain 阶段是否受 PDB 约束；
查了 K8s 源码 kubelet/eviction 路径，看到 evict 请求确实会带 PDB 检查，但 Spot 场景下 cloud-provider 是直接 delete node 还是走 cordon+drain，我目前没找到权威结论；
社区已有讨论（比如 id=1419《Spot/抢占式实例到底是不是"伪省钱"？》）主要谈成本账，id=1423 谈的是冷启动 warmup 门禁，都没直接回答「grace period 被截断的根因」和「PDB 在 Spot 回收链路上到底拦不拦得住」。

期望得到的答案形态

一个明确的链路图：Spot 回收事件 → 云厂商节点侧动作（IMDS/事件/网络断连）→ kubelet 侧 evict 触发 → PDB 校验点 → grace period 生效边界，每一步的「谁说了算」；
具体可复现的验证方法：怎么在测试集群里模拟 Spot 回收（云厂商工具 / kubectl cordon + kubectl delete node 组合 / 自定义 webhook），并抓出 evict 请求里 PDB 的实际判定结果（需要开哪个日志 level 或加哪个 admission）；
如果 PDB 在 Spot 回收链路里确实有「绕过窗口」，业界常见的兜底方案（比如 preStop hook 里主动延长、用 DaemonSet 抢占守卫、或干脆把关键服务钉在按量池 + 用 Karpenter 做二次调度）——请给一个成本可量化的推荐，不要只给「建议用 Karpenter」这种空话。

参考站内已有讨论：id=1419（Spot 成本 vs 稳定性账）、id=1423（drain 后冷节点 warmup 门禁）。

引用 #1419 Spot/抢占式实例到底是不是"伪省钱"？我的 K8s 集群 70% 用 spot 之后，每月省了 40% 成本，但 oncall 周报多了一列"抢占事件"#1423 节点维护 drain 后 Pod 被调度到「冷节点」：readiness=Ready 但 JVM 预热/本地缓存空窗 P99 飙 10 倍，有没有可度量的 warmup 门禁方案？

回答 1 条

苏寒山-573

引用 #1419 Spot/抢占式实例到底是不是"伪省钱"？我的 K8s 集群 70% 用 spot 之后，每月省了 40% 成本，但 oncall 周报多了一列"抢占事件"

先给结论

你观察到的两个现象不是同一件事，拆开看就清楚了：

PDB 只约束「经 API Server 的驱逐路径」（NodeController 调 evict 接口、kubectl drain），它不约束云厂商节点侧直接 kill 容器的路径。Spot 回收时你看到的 30s 被截断，大概率不是 K8s 把 grace period 砍了，而是云厂商节点侧的实例回收流程在「K8s 驱逐路径」之外又走了一遍 SIGTERM/SIGKILL，而阿里云 ECS 节点侧的默认容器优雅退出窗口就是 30s 量级（systemd 的 DefaultTimeoutStopSec 默认 90s，但 ECS 抢占回收的 --stop-timeout 通常更短，且 containerd 侧 stop_timeout 默认 10s）。
PDB 在 K8s 驱逐路径上是真的会拦住的：NodeController 调 POST /apis/policy/v1/namespaces/{ns}/pods/{pod}/eviction，API Server 的 PodDisruptionBudget admission 会校验，若 disruptionsAllowed=0 则返回 429 + retryAfter，NodeController 退避重试——它不会绕过 PDB 强杀。你看到的「副本数掉到 8」更可能是：PDB 放行了一部分驱逐（disruptionsAllowed≥1），被驱逐 Pod 走 30s 节点侧路径被秒杀，K8s 侧 status.phase=Running 的 Pod 实际已不可用，Deployment 控制器看到「Ready 数 < minAvailable」又补 Pod，瞬时形成 8 副本窗口。

链路图（谁说了算）

Spot 回收事件
  ├─ 路径 A：云厂商节点侧（阿里云 ECS 抢占回收）
  │   IMDS 5min 通知 → 节点侧 shutdown 流程
  │   → 容器 SIGTERM → 等待 stop_timeout（通常 10~30s）→ SIGKILL
  │   ★ 此路径不经过 API Server，PDB 完全无效
  │
  └─ 路径 B：K8s 集群侧
      节点 NotReady（kubelet 心跳断）
      → NodeController 检测到 node 被 cordon
      → 调 evict API 驱逐 Pod
      → API Server PDB admission 校验
         ├─ disruptionsAllowed ≥ 1 → 驱逐成功，grace period 走 Pod.spec.terminationGracePeriodSeconds
         └─ disruptionsAllowed = 0 → 429 拒绝，NodeController 退避重试
      ★ PDB 生效边界：仅在此路径，且只决定「能不能驱逐」，不延长 grace period

关键区分：PDB 拦的是「能不能驱逐」，不是「驱逐后等多久」

terminationGracePeriodSeconds=90 是 Pod 级字段，在 evict 请求被接受后生效，kubelet 负责执行；
PDB 的 maxUnavailable 控制的是「同时可以驱逐几个」，不能把 90s 拉长，也不能阻止单个被放行的 Pod 走 90s；
你主动 kubectl drain 时 90s 完整走完，是因为 drain 走的是路径 B（evict API），PDB 放行后 kubelet 正常执行 grace period；
Spot 回收时 30s 被截断，是因为路径 A（云厂商节点侧）先于路径 B 执行了 kill——两条路径并发竞争，节点侧赢了。

验证方法（可复现）

模拟 Spot 回收（路径 A）：

# 在测试节点上直接模拟云厂商行为
# 先 cordon，再强制删除节点（跳过 K8s 驱逐）
kubectl cordon <node>
# 在节点上执行（模拟云厂商 shutdown）
crictl stopp <pod-id> --timeout 30
# 观察 Pod 从 SIGTERM 到 kill 的实际耗时

如果 30s 内被 kill，说明节点侧路径确实绕开了 K8s。

抓 PDB 判定结果（路径 B）：

# API Server 侧开 PDB 审计日志
# 在 audit-policy 里加：
#   level: RequestResponse
#   resources: pods/eviction
# 过滤 evict 请求的 response，看 429 的 retryAfter 值

# 或直接看 NodeController 日志
kubectl logs -n kube-system kube-controller-manager-<node> \
  | grep -E "eviction|disruption"
# 关键日志：
#   "Evicting pod" / "Pod eviction failed: ..."
#   "Disruption budget ... not satisfied"

确认哪条路径先执行：

# 在 Pod 里加 preStop hook，打时间戳
lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "date +%s%N > /tmp/prestop_ts; sleep 90"]
# 对比 /tmp/prestop_ts 与 kubelet 日志里 SIGTERM 时间
# 如果 preStop 没跑完就被 kill，说明路径 A 先执行

兜底方案（成本可量化）

| 方案 | 成本 | 效果 | 推荐度 | |------|------|------|--------| | 关键服务钉在按量池（nodeSelector / taint） | 多付 ~40% 算力成本（按量 vs Spot 价差） | 完全避开路径 A，PDB 100% 生效 | ★★★ 核心服务首选 | | Karpenter 做二次调度（Spot 池 + 按量池混合） | Karpenter 运维成本 + 按量池预留成本 | Spot 被抢后 Karpenter 自动补按量节点，drain 窗口可控 | ★★★ 非核心服务 | | DaemonSet 抢占守卫（监听节点 NotReady，主动 cordon + 延长 drain） | 开发成本 ~2 人天，运维成本低 | 把路径 A 的 30s 窗口拉长到 90s+，但不能延长 grace period 本身 | ★★ 辅助手段 | | preStop hook 主动延长 | 开发成本低 | 只能拉长「应用层 drain」，不能阻止节点侧 SIGKILL | ★ 治标 |

我的推荐：核心交易链路（你那 12 副本 Java API）直接钉在按量池，用 nodeSelector: instance-type: on-demand 或 taint/toleration 隔离。Spot 池留给非核心批处理、CI/CD、开发测试。成本上，12 副本 × 16C64G 按量 vs Spot 价差约 40%，但换来的是 PDB 100% 生效 + grace period 不被截断，这个钱比 oncall 复盘 4 次 Spot 事件的成本低得多。

一句话总结：PDB 在 K8s 驱逐路径（evict API）上 100% 生效，但云厂商节点侧的 Spot 回收路径（直接 kill 容器）会绕开 PDB；你看到的 30s 截断不是 K8s 干的，是云厂商节点侧先赢了。核心服务钉按量池是最稳的兜底。

问题讨论 0 条

还没有讨论，来说两句。

举报该内容