Kubernetes v1.37 WatchCache 初始化为何不再冲击 etcd：429 退避与控制面恢复验证

升级 Kubernetes 后，控制面最怕的不是一次普通的缓存预热，而是 API Server 在 WatchCache 初始化或重新初始化时把大量 list/watch 请求同时压回 etcd。Kubernetes v1.37 的这项改动，重点就在于把恢复阶段的请求量限制在可处理范围内；客户端仍然要正确处理 HTTP 429 和 Retry-After，不能把“请求被拒绝”误读成数据损坏。

v1.37 让 WatchCache 初始化期间的控制面恢复更有边界：API Server 会安全地处理有界请求，超出能力的请求返回 429；升级验收应同时观察缓存恢复、API Server 响应和控制器退避。

v1.37 这条新闻到底改了哪一段路径

Kubernetes 的 API Server 通常先从 WatchCache 读取资源的 list/watch 结果，缓存没有准备好或需要重新初始化时，才会涉及更重的恢复路径。过去最危险的时刻不是“缓存为空”本身，而是许多请求同时等待缓存恢复，又一起把压力传向 etcd。

v1.37 发布说明把这项能力描述为 resilient watchcache initialization：初始化与重新初始化不再制造冲击 etcd 的请求洪峰。API Server 会处理有界请求，超出边界的请求以 429 Too Many Requests 拒绝，并让客户端根据 Retry-After 重新安排请求。

为什么返回 429 反而是恢复保护信号

429 看起来像失败，但在控制面恢复阶段，它比让请求全部排队更容易保护系统。大量控制器如果同时等待同一个资源，会把连接、内存和 etcd 读请求一起推高；有限拒绝让系统保留了继续处理健康请求的空间。

这里要区分两件事：429 表示本次请求没有在当前容量边界内被接受，不表示资源对象不存在，也不表示 etcd 已经丢数据。控制器或客户端应读取响应头中的 Retry-After，结合自身限速策略重试；如果客户端完全无视这个信号，恢复阶段仍可能形成第二波洪峰。

if response.StatusCode == http.StatusTooManyRequests {
    wait := retryAfter(response.Header.Get("Retry-After"))
    backoff.Sleep(wait)
    return retry()
}

上面的代码只是客户端行为示意，实际控制器应使用 Kubernetes 客户端库已有的限速和重试机制，不要在每个业务循环里手写一个无上限的紧密重试。

升级后先观察三组证据

不要只看节点是否 Ready。一次有效的验收至少需要把下面三类证据放在同一时间轴上：

1. API Server：检查 WatchCache 初始化或恢复期间的 429 数量、请求延迟和相关事件，确认拒绝是短时有界行为而非持续故障。
2. etcd：观察读请求、CPU、磁盘延迟和 leader 状态，确认恢复阶段没有出现新的请求尖峰。
3. 客户端：抽查 controller-manager、operator 或自研 informer 的日志，确认遇到 429 后存在退避并最终重新建立 watch，而不是快速循环刷屏。

如果只看到 429 而没有后续恢复，要继续查 API Server 的可用性、客户端 RBAC、网络和 etcd 健康状态。不能因为 429 是预期的保护信号，就忽略它持续存在的可能性。

哪些工作负载最先感受到变化

长时间运行的 informer、operator 和控制器最容易遇到这条路径，因为它们会持续维护 list/watch。它们从 429 恢复后，应该重新建立 watch 并继续推进工作队列；如果本地实现把任意非 2xx 都当成永久错误，就会把一次可恢复的控制面保护变成业务告警。

短命的批处理客户端也要注意：一次调用遇到 429 后，如果任务没有剩余时间窗口，重试不一定有意义。对这类客户端，记录响应、保留任务状态并在下一轮重新拉取，通常比立即连续重试更稳。

采用时别把版本亮点当成容量方案

v1.37 的改动解决的是恢复路径上的请求放大和保护边界，不会替你解决 etcd 磁盘过慢、控制器并发配置过高、API Server 资源不足或客户端重试失控。升级前仍应保留现有的 etcd 快照、控制面监控和回滚路径。

对自研控制器，最值得复查的是错误分类：429 应进入可恢复的退避分支，权限错误、对象版本冲突和不可解析的响应则不能简单套用同一套等待时间。重试次数、最大退避和队列重新入队策略都应该能在日志里看见。

一份可以落地的升级验收顺序

1. 在预发布集群记录升级前的 API Server、etcd 和控制器基线，特别是 list/watch 请求量与客户端重连日志。
2. 升级到 v1.37 后，先观察普通读写，再安排会触发缓存重建或 API Server 恢复的演练，不要直接在业务高峰制造压力。
3. 在同一时间窗核对 429、Retry-After、客户端 backoff 和 watch 重建结果；确认请求被限制后，控制器仍能继续收敛。
4. 若 429 持续增长、etcd 负载不回落或控制器没有重新建立 watch，暂停扩大范围，按控制面、网络、权限和客户端实现分层回退。

相关问题

429 会不会说明 Kubernetes 数据丢了？

不会直接说明数据丢失。429 表示请求在当前处理边界内被拒绝，应该结合后续 watch 重建、资源版本和 etcd 健康证据判断真正状态。

客户端应该固定等待几秒再重试吗？

不建议固定等待。优先读取 Retry-After，再叠加带上限的指数退避和抖动；不同客户端库的默认策略不同，升级验收时应以实际日志核对。

这项改动能替代 API Server 扩容吗？

不能。它降低 WatchCache 初始化阶段的请求洪峰风险，API Server、etcd 和控制器的容量规划仍然需要按真实对象规模与并发负载验证。

总结

Kubernetes v1.37 的 WatchCache 初始化改进，价值不在于让所有请求永不失败，而在于控制面恢复时先守住 etcd 和 API Server 的边界。把 429 看作可观察的保护信号，要求客户端尊重 Retry-After，并用三组证据确认最终恢复，才是这条版本新闻对实际运维最有用的落点。