理解kubernetes’ tools/cache包: part 5

在part 4中，我们在DeltaFIFO结构中单独查看了一些细节，它将逻辑“将此对象添加到请求”请求转换为“添加表示对象添加的事件”操作。 这结束了我们对tools/cache包的结构演练。 从行为的角度来看，显然还有很多东西要看，但是现在值得停下来展示全局。
在下图中，您将看到一个毫无歉意的粗糙和简单混合的，UML，一些Java概念，一些Go类型名称 - 简而言之，一个大杂烩的符号应该证明有助于显示整个包在高水平。 同样，这不是Go结构，Java类或其他任何东西的一对一表示，而是有用的名词和框和线的组合，勾勒出工具/缓存包的一般形状，并希望给出一个 整个事物的可用结构概述：

一般而言，我可能不一致，橙色框表示构成用户希望直接理解或使用的tools/cache框架的概念或结构。 粉色框表示实现相关。 浅蓝色框表示与Kubernetes直接相关的事物。 我已经尝试将UML正确用于其他一切。 大多数（但不是全部）名称都与Go代码足够接近，以一种方式或另一种方式搜索它们应该可以帮助您浏览所有.go文件。
要处理这张大图，你可以打印出来并阅读本系列的前几篇文章，从part 1开始。用SharedIndexInformer概念/类开始图示并按照箭头操作。
在文本上，SharedIndexInformer“是一个”SharedInformer，它管理一个Controller，间接一个Reflector，它使用Kubernetes客户端和ListerWatcher实现来更新特定类型的Store，即DeltaFIFO，其逻辑事件代表修改，添加和删除列出和观看的Kubernetes资源。它从getStore（）方法返回的Store，实际上是一个Indexer，通过Go代码中的缓存类型实现。（特别注意，它的getStore（）方法返回其getIndexer（）方法的返回值，这意味着调用者有权访问的Store不是它作为实现关注内部更新的DeltaFIFO。还记得在如果您手中有任何类型的Store，只有特定函数的调用。）
在本系列的下一篇中，我们将介绍整个tools/cache包的线程和行为问题。