controller-runtime缓存的工作原理及其为何不会使API服务器崩溃
内容提要
Kubernetes控制器利用本地缓存，通过list+watch机制与API服务器同步，避免直接查询。读取操作快速但可能返回旧数据，写入需处理资源版本冲突。索引可优化查询但增加内存开销，缓存可配置以平衡性能与资源。
延伸解读
缓存与API服务器的交互模型
控制器通过list+watch机制维护本地缓存，读取操作不直接访问API服务器，而是从内存缓存中获取。这种设计避免了频繁的API调用，但可能导致读取到旧数据。写入操作则直接发送到API服务器，并通过资源版本进行乐观并发控制。理解这一模型有助于避免因缓存不一致而引发的错误。
索引的实用性与限制
索引可以显著提升按特定字段查询的效率，但仅支持等值匹配，且需要预先注册。索引会占用额外内存，因此不应过度使用。标签选择器（MatchingLabels）并不使用索引，而是全量扫描，性能较差。合理使用索引和标签选择器，可以优化控制器性能。
缓存配置的权衡
通过缓存选项可以限制缓存范围（如命名空间、标签）或使用元数据缓存，以减少内存占用。但需注意，缩小缓存范围可能影响其他控制器对同一类型的访问。对于不常读取或体积较大的对象，可以禁用缓存，直接访问API服务器，但需权衡网络开销。
Q&A
controller-runtime 中的 r.Get 和 r.List 是否直接访问 API 服务器？
不是。在 controller-runtime 中，r.Get 和 r.List 默认从本地内存缓存读取，该缓存由 manager 通过 list+watch 机制维护。只有通过 mgr.GetAPIReader() 或配置 DisableFor 才会直接访问 API 服务器。
controller-runtime 的缓存是如何与 API 服务器保持同步的？
缓存通过 Reflector 组件与 API 服务器同步。Reflector 启动时执行一次 list 获取快照，然后通过 watch 持续接收变更事件，并更新本地存储。如果 watch 断开，Reflector 会使用最后的 resourceVersion 重连；若收到 410 Gone，则重新 list。
为什么在 controller-runtime 中更新对象后立即读取可能得到旧数据？
因为更新操作直接发送到 API 服务器，但缓存通过 watch 异步更新，存在毫秒级的延迟窗口。在这个窗口内，从缓存读取可能返回旧版本。这是最终一致性的体现，应避免依赖即时新鲜度。
controller-runtime 中如何优化按字段查询的性能？
可以通过注册索引（IndexField）来优化。例如，为 Pod 的 spec.nodeName 字段注册索引，然后使用 client.MatchingFields 进行查询，这样会直接通过索引查找，而不是遍历所有对象。注意，索引只支持等值查询，且需要预先注册。
controller-runtime 中如何限制缓存的范围以节省内存？
可以通过 cache.Options 中的 ByObject 配置，为特定类型设置命名空间、标签选择器或字段选择器，从而只缓存需要的对象。还可以使用 Transform 函数裁剪对象字段，或使用 PartialObjectMetadata 只缓存元数据。
controller-runtime 中 resync 和 relist 有什么区别？
resync 是周期性的（默认10小时），它不会从 API 服务器重新拉取数据，而是将本地缓存中的对象重新发送到 DeltaFIFO，触发 OnUpdate 事件，用于补偿可能遗漏的 reconcile。relist 只在 watch 失效（如 410 Gone）或显式重建 informer 时发生，会重新执行 list 操作。
在 controller-runtime 中，如何避免在 reconcile 中使用 time.Sleep 进行延迟重试？
应使用 ctrl.Result{RequeueAfter: 30 * time.Second} 来安排延迟重试。控制器会将请求重新放入工作队列，并在指定时间后触发，同时如果期间有真实事件，会立即触发 reconcile，避免占用 worker 和错过事件。
controller-runtime 中，为什么在事件处理函数中修改对象可能导致问题？
因为事件处理函数接收的对象可能直接来自共享存储，没有深拷贝。修改这些对象会影响其他订阅者。controller-runtime 默认在 Get 和 List 时进行 DeepCopy，但在 Predicate 和 EventHandler 中需要手动 DeepCopy 后再修改。
