client-go源码分析(3):Indexer, cache, threadSafeMap

前言

本文聚焦client-go v11.0.0 controller框架Indexer对象,分析源码indexer的实现。关于client-go的介绍已有优秀文章,可参考第一篇参考文档,本文不再赘述。

1 cache - indexer对象关系

golang的struct和interface之间是弱耦合关系,即struct只需要实现了某个interface的所有方法,就认为该struct实现了该interface。cache和Store对象关系如下:

client-go源码分析(3):Indexer, cache, threadSafeMap_第1张图片
cache UML组件图

从类的实现、组合关系上可见,cache实现了Store interface和Index interface的所有方法,因此cache可以赋值给Store和Index接口。理解threadSafeMap的实现能帮助我们理解cache。

2 理解threadSafeMap的实现

几个内部索引对象及其关系

type IndexFunc func(obj interface) ([]string, error)

type Indexers map[string]indexFunc

type Index map[string]sets.String

type indices map[string]Index

从上述几个对象的命名和关系看,很难理解几个对象的依赖关系。我们首先梳理几个对象之间的关系,其次分析一个pod对象的增、删、改时,几个索引对象的状态迁移如何发生。

2.1 threadSafeMap内部对象关系

client-go源码分析(3):Indexer, cache, threadSafeMap_第2张图片
threadSafeMap内部对象关系示意图

Items:

Items类型map[string] interface{},用来存储runtime.object,map的key(对象键)用函数MetaNamespaceKeyFunc生成,value是runtime.object本身。

Indexers:

indexers类型是map[string]indexFunc,用来存储indexFunc(索引键计算函数),map的key是indexFuncName,value是indexFunc。注意两个要点:1. 区别对象键和索引键;2. {indexName: indexFunc}是外部调用者传入,调用关系参考k8s源码: kubernetes-master\pkg\client\informers\informers_generated\internalversion\extensions\internalversion\deployment.go:

cache.MetaNamespaceIndexFunc函数调用

cache.MetaNamespaceIndexFunc函数注释:

// MetaNamespaceIndexFunc is a default index function that indexes based on an object's namespace.

Indices:

Indices类型map[string]Index。indices是对象快速索引表,map的key是indexName,value是Index对象,即map[string]sets.String。

Index:

Index类型map[string]sets.String。Index map的key是indexFunc计算的值,如MetaNamespaceIndexFunc返回的是namespace,如果使用indexByPodNodeName(源码:kubernetes-master\pkg\controller\daemon\daemon_controller.go)那么返回nodename。

indexSet:

IndexSet是笔者自己取的名字。IndexSet是set.String类型,值是对象键objkey。

到此为止,相信细心的读者可能会发现,threadSafeMap做了两件事:

1)存储:保存k8s runtime.object到items map。

2)索引:为items map的每个对象建立三层索引:第一层是indices map的类别索引,如按'namespace', 'nodeName'索引;第二层是index map的详细类别索引,如'namespace1','namespace2'… 或者'nodeName1','nodeName2'……;第三层是indexSet的对象键。第三层索引才真正索引到runtime.object。

2.2 threadSafeMap关键实现分析

以两个典型的方法func (c *threadSafeMap) updateIndices(oldObj interface{}, newObj interface{}, key string)和func (c *threadSafeMap) deleteFromIndices(obj interface{}, key string)为例分析threadSafeMap内部对象的状态迁移过程。

client-go源码分析(3):Indexer, cache, threadSafeMap_第3张图片
deleteFromIndices实现

deleteFromIndices被Delete,updateIndices等函数调用,它的功能是删除indices的某个索引。deleteFromIndices函数执行步骤如下:

1)遍历indexFunc map c.indexers获取第一层索引indices的类别name,并计算第二层索引index的详细索引类别indexValue;

2)遍历第二层索引表index,依次删除第三层索引表indexSet的对象键。

client-go源码分析(3):Indexer, cache, threadSafeMap_第4张图片
updateIndices实现

updateIndices函数被Add,Update,Replace等函数调用。updateIndices执行步骤如下:

1)updateIndices函数首先删除oldObj的索引键;

2)遍历indexFunc map c.indexers,获取第一层索引indices的索引类别name,并计算第二层索引Index的详细索引类别indexValues(数组);

3)遍历第二层索引Index,依次执行:若第三层索引IndexSet为空则添加一个空set;若非空则添加对象键到第三层索引IndexSet。

3 结语

到此为止threadSafeMap的机制基本分析清楚,cache无非threadSafeMap的封装和扩展,核心机制是一样的,就不再细说 。

4 参考文档

https://www.jianshu.com/p/d17f70369c35

https://blog.csdn.net/weixin_42663840/article/details/81530606

你可能感兴趣的:(client-go源码分析(3):Indexer, cache, threadSafeMap)