k8s client-go源码分析 informer源码分析(3)-Reflector源码分析.doc

【Reflector概述】 在 Kubernetes 的 client-go 库中，Reflector 是一个关键组件，它负责从 Kubernetes API 服务器（kube-apiserver）中获取资源对象的列表并监听这些对象的变更。Reflector 通过 List 和 Watch 操作实现这一功能。List 操作用于获取资源对象的全量数据，而 Watch 操作则用来监控资源对象的增删改事件。Reflector 将这些变更封装成 Delta（增量）对象，并将它们放入 DeltaFIFO（先进先出队列）中。DeltaFIFO 用于管理和同步这些变更，确保 informer 可以有效地处理集群状态的变化。 【健壮性处理机制】 Reflector 设计有健壮性处理机制，能够处理与 API 服务器的连接中断情况。当连接断开时，Reflector 能够自动重新发起 List 和 Watch 操作，以恢复对资源对象状态的跟踪。这种机制使得 informer 成为处理业务逻辑的理想选择，因为它能更好地处理网络波动和服务器故障。 【Reflector核心操作】 1. **List&Watch**：Reflector 初始阶段通过 List 操作获取所有资源对象，然后启动 Watch 过程来监听后续的变更。List 操作返回的结果会被一次性插入到 DeltaFIFO 中，而 Watch 操作则在接收到资源对象的创建、更新或删除事件时，分别调用 DeltaFIFO 的 Add、Update 和 Delete 方法，将事件按顺序加入队列。 2. **Delta包装与投递**：Reflector 收到 API 服务器的变更通知后，会将这些变更转化为 Delta 对象，Delta 包含了对象的当前状态以及变更类型。这些 Delta 对象随后被添加到 DeltaFIFO 中，供 informer 进一步处理。 【Reflector初始化与启动分析】 Reflector 的初始化涉及以下几个关键步骤： 1. **结构体定义**：Reflector 结构体包含了一些重要字段，如 expectedType 表示期望存储在 Store（通常为 DeltaFIFO）中的对象类型，store 存储了 DeltaFIFO 实例，listerWatcher 则是一个实现了 List 和 Watch 方法的接口实例。 2. **expectedType**：这是预期存储在 Store 中的对象类型，用于确保正确处理不同类型的资源对象。 3. **listWatcher**：提供实际的 List 和 Watch 功能，允许 Reflector 与 API 服务器交互以获取资源对象的状态。 4. **store**：Reflector 的 store 实际上是 DeltaFIFO，它是一个特殊的队列，可以按照特定顺序处理 Delta 对象。 5. **启动流程**：Reflector 启动时，会按照预设的周期（period）进行 List&Watch 操作。此外，它还包含一个重试机制，以应对可能的失败情况。 通过以上的分析，我们可以看出 Reflector 在整个 informer 架构中的重要性。它不仅减少了对 API 服务器和 etcd 的频繁请求，还提供了容错能力，确保了系统在面对网络问题或服务器故障时仍能正常工作。结合 informer 的其他组件，如 EventHandler 和 Controller，Reflector 使得开发者能够高效地管理和响应 Kubernetes 集群中的资源变化。