Kubernetes v1.37 manifest-based admission control：API Server 离线时如何保住策略

控制面刚重启时，最怕的不是 API Server 进程起来得慢，而是准入策略还没有回来：etcd 正在恢复，新的工作负载却已经开始写入。Kubernetes v1.37 把基于 manifest 的 admission control 配置提升到 Beta，允许 API Server 从磁盘目录加载 Webhook 与 CEL 策略，让策略在启动阶段就进入请求链路。

它解决的是准入策略的可用性和保护边界，不是把所有策略都变成“永远在线”：管理员仍要正确配置 AdmissionConfiguration、准备静态目录，并验证策略加载失败时的启动行为。

Kubernetes v1.37 这项变化，先看它保护了什么

Kubernetes 官方 v1.37 发布说明把 manifest-based admission control 配置列为 Beta。关键变化不是新增一种策略语言，而是改变策略的装载位置：AdmissionConfiguration 可以通过 staticManifestsDir 指向磁盘目录，API Server 在启动时读取其中的准入配置。

这条路径适合放置需要在控制面早期生效、又不希望完全依赖 API 存储的策略。例如，管理员可以用它保护准入相关资源，避免策略对象本身被普通 API 写操作改掉。这里要分清两个概念：磁盘 manifest 提高的是策略装载的独立性，策略内部调用的外部 Webhook 仍然需要自己的网络与证书可用性。

从 staticManifestsDir 到请求拒绝，链路只有三段

把流程缩短后，性能和可用性都更容易验收：API Server 启动读取 staticManifestsDir，解析 AdmissionConfiguration，再把已加载的 Webhook 或 CEL 规则接到请求处理路径。请求命中规则时，策略返回允许或拒绝，etcd 负责对象持久化，但不再是“策略是否存在”的唯一前提。

一个实用的基线是记录 API Server 重启后的三个时间点：进程就绪、策略加载完成、第一条受策略约束的请求被判定。不要只看 /readyz 返回成功，因为进程就绪不一定意味着你关心的每个策略都加载成功。

etcd 不可用时，策略为什么还能挡住请求

发布说明给出的边界很明确：从 manifest 文件加载的策略在 API Server 启动时执行，并且在 etcd 不可用时仍然工作。这让控制面在存储恢复窗口里保留一层写入保护，尤其适合阻止明显不合规的对象继续进入请求处理链。

但“策略还能执行”不代表“请求一定成功”。如果准入链里包含需要访问外部服务的 Webhook，网络、TLS、超时和 failurePolicy 仍然决定请求最终结果；静态目录只是让策略配置本身不依赖 API 存储，不能替外部依赖提供可用性。

压测时可以用两组数字做对照：etcd 正常时的准入延迟分位数，以及模拟 etcd 不可用后的策略判定结果。这里不要拿一次 kubectl apply 成功就下结论，应至少覆盖一条允许样本和一条必拒样本，并记录 API Server 日志中的拒绝原因。

采用前要接受的三个现实约束

静态目录不是热更新配置中心

目录文件变化如何被重新读取，要以 v1.37 具体实现和运维流程为准，不应把它当作每次保存就立即生效的动态配置。更稳妥的做法是把目录变更纳入 API Server 重启或受控滚动流程，并在变更后重新做允许、拒绝和回滚验证。

保护准入资源不等于保护所有业务对象

基于 manifest 的策略能在控制面早期提供保护，但规则的匹配范围、资源版本和 failurePolicy 仍要由管理员设计。若策略只覆盖某个 API group，其他资源不会因为“用了 staticManifestsDir”自动受保护。

故障演练要分离存储故障与策略故障

建议分别演练 etcd 不可用、策略文件损坏、Webhook 超时和 API Server 重启。每种故障都记录请求返回码、审计事件和恢复动作，避免把所有拒绝都归因于 etcd。

常见问题

升级 Kubernetes v1.37 就会自动启用磁盘准入策略吗？

不会。需要管理员配置 AdmissionConfiguration、指定 staticManifestsDir，并准备符合要求的策略 manifest；升级本身只提供 Beta 能力。

etcd 暂时不可用时，所有准入 Webhook 都还能工作吗？

不能这样推断。磁盘加载的策略配置仍可执行，但外部 Webhook 的网络、证书和超时依赖仍然存在，最终结果要按具体链路验收。

如何判断策略真的参与了请求？

同时提交一条符合规则的对象和一条明确违规的对象，核对返回状态、API Server 日志与审计记录；只看进程 Ready 不足以证明准入链生效。

把 Beta 能力放进发布检查表

第一次采用时，先在非生产控制面准备静态目录，验证权限、文件格式和启动日志；再完成正常存储、etcd 故障、策略拒绝、Webhook 超时四类场景。只有当策略加载状态和请求结果都能被复查，才适合把这项 v1.37 能力纳入正式升级窗口。