gRPC是由google开发，是一款跨平台，跨语言，开源的远程过程调用(RPC)系统。Docker v1.12.3就是通过gRPC调用containerd的。所以本次笔记介绍基于官方例子改写的一个例子，分别用Go和Python实现。

环境搭建

略(由于google.golang.org被墙，所以我是通过containerd源码包中的src来解决依赖的，不方便)。

garbagecollector的功能主要有以下三点：

1. 执行联级删除时(资源删除由apiserver完成)，回收子资源；
2. 执行非联级删除时，删除子资源的联级关系，再回收资源；
3. 维护有资源之间的联级关系表。

layStore负责Docker的layer的管理，具体有镜像层的管理，容器init层的管理，容器读写层的管理。layerStore的管理目录为/var/lib/docker/image/aufs/layerdb，主要有以下目录：

1. mounts: 存储容器挂载信息，有init-id, mount-id, parent文件。

referenceStore用来管理镜像名称和id之前的关系，主要和/var/lib/docker/image/aufs/repositories.json打交道。本次分析将介绍关于referenceStore的代码。

referenceStore

来看下referenceStore(即store)的定义，在/reference/store.go中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

type store struct {
	mu sync.RWMutex
	// jsonPath is the path to the file where the serialized tag data is
	// stored.
	jsonPath string
	// Repositories is a map of repositories, indexed by name.
	//***map[dirage:map[dirage:v1:sha256:987fbbdd3e5ded64e38b15f3ee32ed5e59982313dc5331249cb47c07866b9746] etcd-cluster:map[etcd-cluster:v1:sha256:cf6ce5c776de4d51725077009fc473576ae04befed4c73bb049ae2e9376e20df]***//
	Repositories map[string]repository
	// referencesByIDCache is a cache of references indexed by ID, to speed
	// up References.
	//***sha256:002883be70c0fb86ee87a97ac9066091adabe370efb9d9bfeb858fb3d69596e4:map[mysql:v1:0xc42047d120]***//
	//***0xc42047d120为结构体地址，Named就是image名字和tag***//
	referencesByIDCache map[image.ID]map[string]Named
}
// Repository maps tags to image IDs. The key is a stringified Reference,
// including the repository name.
type repository map[string]image.ID

之前在”Docker镜像存储分析”中已经介绍过Docker是如何组织镜像存储目录的。在Docker中，主要有三个store来负责对镜像进行管理：

1. imageStore: 负责imagedb目录管理；
2. layerStore: 负责content目录管理；

什么是NamespaceController

NamespaceController负责Namespace的删除。我们知道，当我们删除Namespace的时候，Apiserver并不会删除Namespace，仅仅设置了deletionTimestamp字段。所以，整个Namespace的删除工作由NamespaceController完成。NamespaceController会轮询并处理每一个Namespace。

demo

我们知道，Kubernetes中ListWatch机制，组件可以先使用List获取全量的对象，然后再通过Watch建立与Apiserver的长连接，获取对象的变化，并进行相应的处理。并次demo就展示Go语言如何建立长连接，及以json对象为例，说明服务端如何发送数据，client端如何接收数据。

什么是finalizer机制

在Kubernetes中，在删除资源时，常常需要做些额外的操作，如删除namespace时，需要删除该namespace下所有资源，然后再删除namepsace；又如联级删除rc时，需要删除该rc所关联的pods，然后再删除rc。finalizer机制就是为了这些功能而加入的。
在v1.5.2中，主要有两个finalizer，”namespace”和”orphan”，其中”namespace”对应namespace的删除；”orphan”对应联级资源的删除。
finalizer机制有点像标签，一个标签代表着某个处理。比如，到超市购物，我们通常会列一个购物清单，然后买一件物品，就在购物清单上把对应的物品名称划掉，当购物清单上的物品名称全部划掉的时候，那么，就可以去结算了。finalizer机制也一样，如果需要某项处理时，就在object上贴上该项的标签，当程序处理完时，再把该项的标签去除。所以我们可以给object贴上很多finalizer标签，触发处理后，如果检测到不存在finalizer标签了，则认为对于该object来说，所有finalizer处理全部完成。

之前我们分析过SharedIndexInformer，SharedIndexInformer提供了一种单reflector多处理函数的informer机制。本次分析将来介绍kube-controller中的sharedInformerFactory。

什么是sharedInformerFactory

我们知道，如果一个informer使用一个reflector，那么过多的listwatcher会导致系统负载过重。对同一类资源进行操作的多个informer可以
共享一个reflector，这样将会节省很多资源。而SharedIndexInformer就提供了这样一种机制，允许用户自己在SharedIndexInformer中添加处
理函数。sharedInformerFactory就是利用SharedIndexInformer的这种特性：在sharedInformerFactory中缓存着多个SharedIndexInformer，
如pod资源对应的sharedIndexInformer，现在只要往该sharedIndexInformer中添加处理函数，即可完成多个informer所要求的处理。
sharedInformerFactory定义在/pkg/controller/infoermers/factory.go中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

type sharedInformerFactory struct {
	client        clientset.Interface
	lock          sync.Mutex
	defaultResync time.Duration
	informers map[reflect.Type]cache.SharedIndexInformer
	// startedInformers is used for tracking which informers have been started
	// this allows calling of Start method multiple times
	startedInformers map[reflect.Type]bool
}
// NewSharedInformerFactory constructs a new instance of sharedInformerFactory
func NewSharedInformerFactory(client clientset.Interface, defaultResync time.Duration) SharedInformerFactory {
	return &sharedInformerFactory{
		client:           client,
		defaultResync:    defaultResync,
		informers:        make(map[reflect.Type]cache.SharedIndexInformer),
		startedInformers: make(map[reflect.Type]bool),
	}
}

显然，dynamicClient还需要用户自己设置resource资源。其实更多的时候用户只是希望如果要操作pod，那么生成一个podClient；如果要操作service，那么 生成一个serviceClient。ClientSet就是满足用户的这种需要。

ClientSet

ClientSet是多个Client的集合，定义在/pkg/client/clientset_generated/release_1_5/clientset.go中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// Clientset contains the clients for groups. Each group has exactly one
// version included in a Clientset.
//***Fankang***//
//***v1.5中的client***//
type Clientset struct {
	*discovery.DiscoveryClient
	*v1core.CoreV1Client
	*v1beta1apps.AppsV1beta1Client
	*v1beta1authentication.AuthenticationV1beta1Client
	*v1beta1authorization.AuthorizationV1beta1Client
	*v1autoscaling.AutoscalingV1Client
	*v1batch.BatchV1Client
	*v2alpha1batch.BatchV2alpha1Client
	*v1alpha1certificates.CertificatesV1alpha1Client
	*v1beta1extensions.ExtensionsV1beta1Client
	*v1beta1policy.PolicyV1beta1Client
	*v1alpha1rbac.RbacV1alpha1Client
	*v1beta1storage.StorageV1beta1Client
}