如何用 Kubernetes PartialObjectMetadata 降低控制器读取成本？
题目与背景
一个控制器只需要对象名称、标签、命名空间和 resourceVersion，却要读取大量 Pod 的完整 spec 与 status。请使用 Kubernetes 的 metadata-only 内容协商设计列表请求，并说明不支持部分响应的聚合 API、406 错误和后续 watch 如何处理。
面试官考察什么
- 能否正确构造
Accept参数并区分单对象与列表表示。 - 能否理解部分响应不是字段过滤补丁，而是另一种 API 表示。
- 能否设计 406、版本兼容和全量对象回退，避免控制器启动失败。
- 能否保持 list/watch 的
resourceVersion和缓存一致性。
先问清楚的澄清问题
资源与服务器边界
目标资源是内置 API、CRD 还是聚合 API？所有 apiserver 和代理是否支持 metadata-only 表示？
使用模式
客户端只做存在性和标签索引，还是后续还要读取对象 spec？需要 list 后立即 watch 吗？
失败策略
部分响应不可用时允许读取完整对象，还是必须显式失败以保护带宽和内存预算？
30 秒回答框架
我会为列表请求使用 application/json;as=PartialObjectMetadataList;g=meta.k8s.io;v=v1，只接收 metadata 和列表的 resourceVersion。在 Accept 中加入较低质量的 application/json 作为回退，客户端根据响应的 kind 判断实际表示；若没有回退则把 406 视为能力不支持而非重试风暴。list 成功后用返回的 resourceVersion 建立 watch，并为缓存记录表示类型。
深入解答步骤
1. 区分两种表示
单对象请求使用 as=PartialObjectMetadata，集合请求使用 as=PartialObjectMetadataList。返回对象的 spec 和 status 被省略，只保留 metadata；这减少序列化、网络和客户端解码成本，但不能满足需要业务字段的调用方。
2. 构造带回退的请求
GET /api/v1/pods
Accept: application/json;as=PartialObjectMetadataList;g=meta.k8s.io;v=v1, application/json;q=0.9首选表示不可用时，服务器可以选择普通 JSON。客户端必须检查响应的 kind、apiVersion 和 Content-Type，不能因为 HTTP 200 就假设拿到部分对象。
3. 处理严格模式与 406
若 Accept 只声明部分表示，而目标 API 不支持，Kubernetes 返回 406。控制器应把 406 记录为能力探测结果，按策略切换完整对象、跳过该资源或提示配置错误；不能无限重试相同 Accept，也不能把 406 当作临时网络故障。
4. 处理聚合 API 和 CRD
内置 API 通常支持 metadata-only，但聚合层后的 API 可能不支持。CRD 或第三方 API 的实现也可能只提供完整对象。启动时可按资源和服务器分组探测能力，缓存结果并设置过期时间；不要把一个资源的成功能力推广到所有资源。
5. 保持 list/watch 一致
列表响应中的 resourceVersion 仍是后续 watch 的起点。客户端要保存它，并处理 watch 的过期、断开和重新 list。metadata-only 只改变对象表示，不改变资源版本语义；回退到完整对象时也要用同一版本建立缓存，避免混入旧数据。
6. 设计缓存与升级
缓存条目应标记表示类型和字段可用性。需要 spec 的路径不能读取 metadata-only 条目后假设字段存在，而应按名称发起完整 GET。升级服务器或代理后重新探测 Accept 能力，避免长期保留不必要的完整对象路径。
7. 衡量成本和安全性
比较请求字节数、解码 CPU、堆峰值、list 延迟、watch 重连率和完整 GET 比例。标签、注解和 ownerReferences 仍可能包含敏感信息，权限检查不会因只返回 metadata 而消失；日志和指标也不应直接输出全部注解。
高质量示例回答
我会为列表首选 PartialObjectMetadataList，并以较低质量的普通 JSON 作为回退。客户端根据响应 kind 验证实际表示，406 只触发一次能力切换。保存返回的 resourceVersion 建立 watch，缓存记录字段能力；聚合 API、CRD 和需要 spec 的路径分别探测与读取，最后用字节、CPU、内存和重连指标证明收益。
常见错误
- 对列表使用单对象的
PartialObjectMetadata参数。 - 以为 metadata-only 是服务器端任意字段过滤，忽略返回 kind。
- 没有回退就把 406 当成可重试的 5xx。
- 将内置资源的能力假设推广到聚合 API 或所有 CRD。
- 丢弃 list 的
resourceVersion，重新 watch 时从错误位置开始。 - 只测响应大小，不测解码 CPU、堆峰值和重连成本。
追问与回答
为什么列表要使用 PartialObjectMetadataList？
集合请求返回的是列表表示，PartialObjectMetadataList 明确表示每个条目只有 metadata。单对象表示用于单个 GET；两者不能混用后再靠客户端猜测。
服务器不支持部分响应时怎么办？
Accept 同时声明普通 JSON 回退时，检查响应 kind 后使用完整对象；严格模式则把 406 记录为能力缺失并按资源策略跳过或报错。不要无限重试同一请求。
metadata-only 会改变 resourceVersion 吗？
不会。它改变对象表示，不改变资源版本语义。list 返回的版本仍用于后续 watch 和缓存一致性。
CRD 都支持这种请求吗？
不能假设。聚合 API 和 CRD 可能不支持部分表示，启动时应按资源探测并缓存能力。
什么时候必须读完整对象？
需要 spec、status 或业务字段进行决策时，metadata-only 不足。此时先用 metadata 建立索引，再按名称或事件触发受控的完整 GET。