【kube-apiserver】List、Pagination 与一致性 List：continue token 与 etcd Range 成本
内容提要
本文分析Kubernetes中`kubectl get pods -A`在大集群下变慢的原因，指出常见误判为etcd慢，实际可能是cacher或etcd3的List路径问题。文章详解了`resourceVersion`语义（`rv=""`走etcd强一致，`rv="0"`走缓存）、continue token的编码结构、分页成本模型，以及label selector在etcd侧无索引导致的全量扫描放大问题，并给出优化建议。
延伸解读
continue token 不是 etcd 游标
continue token 常被误认为 etcd 游标，实际是 apiserver 内部的分页状态，编码了下一批起始 key 和 resourceVersion 快照。它由服务端生成，对客户端不透明，且不能跨版本缓存。理解这一点有助于避免在分页调试中走弯路。
rv="" 与 rv="0" 的性能差异
rv="" 强制走 etcd 强一致读，每次分页都触发 etcd Range；rv="0" 则从 cacher 内存读取，无 etcd I/O。在大集群下，若业务允许一定延迟，使用 rv="0" 可显著降低 etcd 压力，但需注意其可能读到稍旧数据，不适合 read-after-write 场景。
label selector 放大 etcd Range 成本
etcd 不理解 label selector，仅做 key 前缀过滤。带 label selector 的 List 请求，apiserver 需拉取全量对象再内存过滤，导致 etcd 扫描量远大于实际返回量。若命中率低，即使 limit 很小，也可能扫描大量 key，这是大集群下 List 变慢的常见原因。
field selector 的索引限制
etcd 是 key-value 存储，value 不参与索引。apiserver 仅对部分常用 field selector（如 spec.nodeName）转换为 etcd key 前缀过滤，其余字段仍需全量扫描。复合 selector 或未注册字段无法利用索引，设计查询时应尽量使用受支持的字段。
Q&A
为什么 kubectl get pods -A 在大集群下会变慢？
常见误判是 etcd 慢，实际上可能是 cacher 用 rv=0 从内存 store 服务，但 label selector 在 apiserver 侧全量过滤；或 rv="" 强制打穿 etcd，触发大 Range。
Kubernetes 中 resourceVersion 为空字符串和 "0" 有什么区别？
resourceVersion 为空字符串（""）表示强一致性读，直接访问 etcd；resourceVersion="0" 表示允许任何已知版本，可从缓存（Cacher）服务。
Kubernetes 分页中的 continue token 是什么？它包含哪些信息？
continue token 是 base64 编码的 protobuf 结构，对客户端不透明，包含下一批扫描的 etcd key 起点（startKey）和首页 List 时的 resourceVersion 快照，用于保证多页结果来自同一一致性快照。
为什么带 label selector 的 List 请求会放大 etcd Range 的成本？
etcd 不理解 label selector，只做 key 前缀过滤；apiserver 需要接收所有对象（按 limit 分批），在内存中逐条匹配 label selector。若命中率低，apiserver 需要扫描大量 key 才能凑满一页，导致 etcd 侧扫描量远大于实际返回量。
使用 rv="0" 进行 List 时有哪些限制？
rv="0" 的结果可能略早于当前时刻，不适用于需要 read-your-own-write 一致性的场景；若 Cacher 未 Ready 或 watchCache 的 RV 落后于期望，可能回退到 etcd 路径。
field selector 在 etcd 中是否有索引？
etcd 是 key-value 存储，value 不参与索引，因此 field selector 在 etcd 中没有专用索引。apiserver 会将部分常用 field selector（如 spec.nodeName、metadata.name）转换为 etcd key 前缀过滤，但复合 selector 或未注册字段仍需 apiserver 侧全量扫描。
