通用面试：如何为 Kubernetes Pod 级资源伸缩制定准入政策？
题干与适用场景
平台团队准备开放 Kubernetes Pod 级 CPU/内存 resize。业务团队希望自动调优，财务担心成本失控，SRE 担心内存变更触发容器重启。请制定一套跨团队准入、审计、事故响应和回滚政策。
面试官考察点
- 能否把技术能力转成清晰的责任、权限和预算边界。
- 能否用风险分级决定哪些工作负载可自动伸缩。
- 能否把状态条件、重启策略和 SLO 作为审批依据。
- 能否通过审计和演练证明政策在事故中可执行。
回答前需要澄清的问题
- 哪些命名空间、环境和工作负载允许 resize？
- 谁批准上限、谁承担成本，谁有紧急冻结权限？
- 如何识别容器级
resizePolicy、有状态连接和内存重启风险？ - 组织是否已有配额、变更窗口、审计和事故指挥流程？
30 秒回答
我会先按环境、业务关键性和容器重启风险分级：开发环境可自动调优，生产关键服务默认需审批。政策固定最小/最大 CPU 和内存、步长、冷却时间、命名空间配额和 SLO 护栏，要求请求通过 /resize 子资源并记录 owner、原因和 observedGeneration。准入控制器拒绝越界或无法解释的请求，事件中区分 Pending、InProgress、Infeasible 和 Deferred。审计记录成本与重启，定期演练冻结、回滚和责任交接。
分步骤深入解答
定义风险等级
按环境、SLO、数据状态、连接可中断性和容器 resizePolicy 分级。关键有状态服务、支付和控制面默认禁止自动内存变更；低风险无状态服务可在上限内自动调整。
建立准入规则
规则至少包含 namespace allowlist、资源上下限、步长、冷却时间、节点容量、配额、变更窗口和必须标签。任何请求都要说明指标来源、目标和预计成本。
绑定 Kubernetes 状态
政策要求控制器读取 desired/actual resources、observedGeneration 和 resize conditions。只有 InProgress 完成且实际值符合目标才算成功；Pending、Infeasible 或 Deferred 必须进入队列并显示原因。
处理重启与回滚
内存变更可能触发容器重启，政策要求服务声明连接排空、状态恢复和最大重启次数。超过阈值自动冻结，恢复最后稳定预算，不允许只把 Pod phase Running 当作无事故。
做好成本与审计
记录每次变更前后 CPU/内存、持续时间、成本估算、owner、审批人和结果。财务按 namespace、团队和工作负载查看预算偏差，SRE 查看 SLO、OOM 和重启关联。
事故演练与治理迭代
定期演练节点容量不足、控制器失联、错误预算和大规模回滚。演练后更新规则、runbook 和联系人；任何例外都要有过期时间，避免临时白名单永久存在。
高质量示范回答
我会把 Pod resize 作为受治理的变更能力，而不是默认开放的开关。根据环境、SLO、状态和 resizePolicy 分级，关键有状态服务默认需要审批。准入规则固定 namespace、上下限、步长、冷却、配额、节点容量和变更窗口，并要求通过 /resize 子资源、带 owner、原因和 observedGeneration。控制器只在实际状态完成后确认成功，Pending/Infeasible/Deferred 都要可见。内存重启有排空和恢复门槛，超限就冻结并回滚。审计连接成本、SLO、OOM 和 restartCount，定期演练冻结、回滚和责任交接。
常见错误
- 只写资源上下限，不定义审批人、冻结权和责任边界。
- 允许所有生产 namespace 自动内存伸缩。
- 忽略
/resize状态条件和容器重启策略。 - 用 Pod phase Running 代替业务无中断证据。
- 没有成本审计、例外过期时间和回滚演练。
- 发生事故时才临时寻找 owner 和 runbook。
追问及应对
哪类服务应默认禁止自动内存 resize？
无法快速排空连接、状态恢复代价高或重启会影响一致性的关键服务，应先审批并完成演练。
如何防止团队绕过政策直接改 Pod？
用准入控制器、RBAC、字段管理和审计拒绝未授权写入；紧急权限要限时、可追踪并自动过期。
成本与 SLO 冲突时谁决定？
政策预先定义优先级和预算阈值，超阈值由指定业务与 SRE 负责人共同决定，不能由控制器默默选择。
如何判断政策有效？
比较越界请求拦截率、SLO 回归、OOM、重启、预算偏差、回滚耗时和演练完成率，并按团队复盘调整。