题干与适用场景
这是面向平台和 Kubernetes 工程师的控制平面系统设计题。Kubernetes v1.36 引入服务端分片 List/Watch，属于需要开启 ShardedListAndWatch 特性门控的 alpha 功能。把它视为可选优化，控制器在门控关闭时仍须正确。
面试官考察点
- 精确覆盖键空间且只归属一次的分片模型。
- 正确的初始 List、resourceVersion 和 Watch 重连。
- 发现 API Server 忽略 selector 的机制。
- 重新分片、副本变化，以及重叠和缺口的权衡。
- API Server CPU、网络、informer 内存与恢复风暴的容量推理。
归属键是什么？
alpha 实现支持 object.metadata.uid 和 object.metadata.namespace。UID 哈希分布稳定；namespace 哈希可保持租户局部性但可能倾斜。选择会改变均衡、隔离边界和迁移成本。
正确性目标是什么？
确认是否接受至少一次协调，以及重复处理是否幂等。业务副作用不能重复时，应增加持久化工作键和 fencing，不能只依赖事件流。
API Server 和客户端能否同时升级？
默认存在混合版本，除非平台团队证明全部升级。控制器要检查响应元数据，门控关闭或服务端不支持时回退到本地过滤，不能假称负载已降低。
30 秒回答框架
“我会把确定性的 64 位哈希空间切成不重叠范围，每个范围分配给一个副本。每个 informer 在 List 和 Watch 都发送 shard selector，并验证响应包含匹配的分片元数据。缺少确认时安全回退到本地过滤或关闭优化。重新分片使用 generation 和交接协议，配合重叠、幂等协调及覆盖率、重复数、延迟和回退流量指标。”
分步骤深入解答
分区与分配
用环上的半开范围 [start, end) 表示 64 位空间。每个范围持久化 generation、owner 和 lease。两个副本可各占一半，更多副本由控制器管理范围表。不要只按副本序号推导归属，否则重启可能制造缺口。
副本 A： [0000..., 8000...)
副本 B： [8000..., 1000...)让 List 和 Watch 成为同一协议
初始 List 和每次 Watch 重连都携带相同 selector 与 resourceVersion。informer 收到完整初始列表后再替换本地 store，并从返回的 resourceVersion 开始 Watch。遇到 410 Gone 或版本过期时，只为该分片重新 List，不能盲目重放其他范围。
验证服务端支持
v1.36 博客描述了回显已应用 selector 的 shardInfo 响应字段。缺失时要假设服务端返回完整集合。客户端可本地过滤保持正确，但必须记录回退指标并施加背压，避免不支持的服务端让每个副本都占满内存。
无缺口地重新分片
创建新 generation 的范围。交接期间旧 owner 继续协调，新 owner 先完成 List 预热，并在已知 resourceVersion 上建立 Watch。双方 ready 后才提交归属变化；协调幂等时重复事件可接受。ready 失败则让 lease 过期并保留旧 owner。
容量与失败路径
服务端过滤减少被丢弃对象的字节和反序列化成本，但 API Server 增加哈希和 selector 计算。用特性门控、每个控制器的并发上限和灰度保护它。API Server 过载时限制重连并指数退避，不能让所有副本同时 relist。
高质量示范回答
“我会用对象 UID 的确定性哈希建立带 generation 的范围表。informer 在 List 和 Watch 都携带 selector，只有看到 shardInfo 才把优化视为生效。缺失字段时回退到本地过滤，并使用全局并发预算。重新分片创建新 generation，让新 owner 从指定版本预热，ready 后再切换 lease；协调幂等使短暂重叠安全。灰度开启门控，并比较 API CPU、字节、List 延迟、Watch 重连、分片覆盖、重复数和回退率。”
常见错误
- 按副本序号分片 → 重启会改变归属并制造缺口 → 持久化带 generation 的范围表。
- 只给 Watch 加 selector → 初始 List 仍过载且可能与流不一致 → List 和 Watch 使用同一 selector 与版本规则。
- 信任不支持的服务端 → 每个副本收到完整流 → 要求
shardInfo并暴露回退流量。 - 瞬间移动范围 → 交接期间可能丢事件 → owner 重叠、generation fencing，并让协调幂等。
- 只看控制器 CPU → API Server 哈希或重连风暴不可见 → 同时监控控制平面与客户端指标。
评分标准与自检
评分分区正确性、List/Watch 语义、回退、重新分片、容量和可观测性。强回答应明确不变量：每个对象属于一个活动范围 generation，交接有 resourceVersion 边界；还要说明幂等协调时重复比缺失更安全。
追问及应对
某个 namespace 特别大怎么办？
优先用 UID 哈希均衡，或把热点 namespace 拆成多个 UID 范围。测量各范围负载，不要假设对象数量相等。
如何发现静默缺口？
用全局对象数与分片数并集做抽样对比，记录 selector generation，并周期性创建经过所有范围的合成对象。对延迟或覆盖漂移告警。
API Server 升级期间怎么办？
在所有服务端点的 canary 都返回 shardInfo 前保持门控关闭。混合响应触发回退和有界重连速率。
控制器会重复处理对象吗？
交叠或重连期间会。用对象版本和持久化工作键保证副作用幂等；不能为了避免重复而接受无限的丢状态风险。