Kubernetes 混合版本代理如何保障控制面升级期间的 API 兼容？
题干与适用场景
在一个多可用区 Kubernetes 集群中，控制面需要从 v1.35 滚动升级到 v1.36。升级窗口内，不同 kube-apiserver 可能认识不同的资源版本，客户端请求某个 API 服务器时可能得到误导性的 404。请设计并解释 Mixed Version Proxy（混合版本代理）如何路由请求、限制安全边界、观测效果并支持回滚。回答要区分 Kubernetes v1.36 的 Beta 行为与传统版本偏差策略。
面试官考察点
- 是否能把版本偏差、发现缓存和 API 可见性拆成独立故障域。
- 是否理解代理只处理资源请求，不能替代 API 版本转换或存储迁移。
- 是否能说明对等 API 服务器发现、转发、身份透传和循环避免。
- 是否把升级安全、审计、超时、重试和回滚纳入整体设计。
回答前需要澄清的问题
- 升级是同一集群内的滚动替换，还是跨集群迁移？这里按同一集群、多个对等 API 服务器处理。
- 客户端主要使用 Kubernetes 原生资源，还是包含聚合 API 服务器和 CRD？代理对未知资源版本的覆盖范围需要单独确认。
- 控制面是否启用统一负载均衡、mTLS、审计与集中指标？这些决定身份透传和故障定位方案。
- 允许的额外延迟、不可用窗口和回滚时间分别是多少？
30 秒回答框架
先说明问题：滚动升级时，请求落到旧 API 服务器会把“新版本资源”误判为不存在。然后给出路径：入口 API 服务器做发现与本地判定，若资源版本未知则把请求转发给兼容的对等 API 服务器；响应、状态码和审计身份返回给原请求方。最后补上边界：依赖版本偏差策略、禁止循环代理、限制代理身份、对转发失败使用明确错误，不用重试掩盖控制面故障，并通过指标与灰度开关回滚。
分步骤深入解答
1. 请求分类与转发决策
API 服务器先解析请求的 group、version、resource 和动词。若本地已注册该资源，直接走本地认证、授权、准入和存储路径；若请求版本在本地发现信息中未知，则查询对等 API 服务器的可用版本。只有对等方明确支持该资源版本时才转发，否则返回可区分的错误。代理不猜测版本，也不把普通业务 404 改写成转发。
2. 对等发现、身份与循环控制
对等 API 服务器应来自受控的控制面成员列表或安全的内部发现机制，连接使用集群既有的服务身份与加密通道。转发请求携带原始用户身份、组、授权头和审计上下文，但代理本身仍需执行本地授权边界。请求增加 hop 标记或等价的内部元数据；看到已代理标记时禁止再次转发，避免 A 到 B 再回 A 的循环。
3. 一致性与失败处理
资源读取可能在不同 API 服务器间看到短暂不同的发现缓存，因此客户端应以服务器返回的资源版本和 resourceVersion 为准。转发只在目标服务器可用且版本兼容时发生；连接超时、目标拒绝或响应版本不匹配都应快速失败并记录原因。对写请求避免无界重试，防止重复创建或更新；需要重试时依赖幂等键或客户端的明确重试策略。
4. 发布、观测与回滚
先在非高峰期升级一个 API 服务器，观察代理命中率、转发延迟、未知版本错误、5xx、审计完整性和发现收敛时间，再扩大批次。v1.36 中 Mixed Version Proxy 进入 Beta 并默认启用，但仍应结合版本偏差策略和发行版支持矩阵验证。出现异常时停止后续替换、将流量固定到已知兼容节点，必要时关闭特性门并回滚控制面；保留转发链路与原始身份的审计记录。
高质量示范回答
我会把 Mixed Version Proxy 当作升级期间的控制面兼容层，而不是新的 API 网关。入口服务器先完成认证、授权和准入前的请求分类；本地认识的资源走本地路径，只有本地发现未知但对等服务器明确支持的资源才转发。转发连接使用控制面已有的安全身份，透传原用户和审计上下文，并设置单跳标记防止循环。对等服务器返回的状态码和响应体要保留语义，超时或版本不匹配立即失败，写请求不做无界自动重试。
我会用灰度升级验证这条链路：记录本地命中、代理命中、目标版本、延迟、错误类型和审计关联 ID；当命中率或 5xx 超过阈值时暂停替换并把流量留在兼容节点。v1.36 的 Beta 默认开启不等于可以跳过发行版验证，我仍会检查版本偏差策略、聚合 API 和 CRD 的适用范围。回滚包括停止升级、恢复控制面成员、关闭特性门（如果发行版允许）和核对发现缓存，确保客户端不会继续使用过期能力。
常见错误
- 把代理描述成任意 API 版本转换器，忽略它主要解决未知资源版本的路由问题。
- 只说“转发到新节点”，没有说明对等发现、身份透传和循环保护。
- 对所有 404 都转发，导致真实的资源不存在被放大成控制面流量。
- 对写请求进行无条件重试，造成重复副作用。
- 只看平均延迟，遗漏发现收敛、审计完整性和版本偏差约束。
追问及应对
追问一：聚合 API 服务器或 CRD 也能自动代理吗？
先确认该资源是否属于 Mixed Version Proxy 的实现范围。聚合 API 服务器有独立的发现、认证和可用性边界，不能因为主 API 服务器能代理原生资源就推断它也能代理。回答中应给出能力矩阵和明确的“不支持时快速失败”路径。
追问二：如何防止转发放大控制面故障？
设置单跳、超时、并发上限和熔断；转发失败不回源无限重试。把代理命中率、目标错误和排队长度纳入告警，并在升级控制器中设置批次暂停条件。
追问三：客户端发现缓存过期怎么办？
客户端仍需遵守 Kubernetes 的发现与版本偏差策略。服务器端代理只能降低滚动升级期间的错误 404，不能替客户端永久缓存新资源，也不能替代 API 资源的版本迁移。必要时让客户端重新发现并使用明确的 API 版本。