本文是对kubernetes GC proposal的解读分析，是对GC in kubernetes v1.3的内部结构剖析，并记录了 其中一些关键点，以便日后能更好的温故而知新。

kubelet GC ?

在v1.3版本之前，kubernetes也有一个GC，只不过那是kubelet GC,

"Garbage collection is a helpful function of kubelet that will clean up unused images and unused containers. kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes."

上面是对kubelet GC最好的解读，就是负责本地node节点的unused images and unused containers的GC，以回收node资源。

kubernetes GC architecture

在k8s v1.3的GC，主要目标是：

• Supporting cascading deletion at the server-side. • Centralizing the cascading deletion logic, rather than spreading in controllers. • Allowing optionally orphan the dependent objects.

这里的GC，可以看成是kubernetes内置一个controller，实际上，它也确实是集成在kube-controller-manager中。由4个模块组成：Scanner，Garbage Processor，Propagator and Finalizer，其结构图如下：

对各个模块职责的具体解释如下： ###Scanner:

• Uses the discovery API to detect all the resources supported by the system.
• Periodically scans all resources in the system and adds each object to the Dirty Queue.

###Garbage Processor:

• Consists of the Dirty Queue and workers.
• Each worker:
• • Dequeues an item from Dirty Queue.
• • If the item's OwnerReferences is empty, continues to process the next item in the Dirty Queue.
• • Otherwise checks each entry in the OwnerReferences:
• • • If at least one owner exists, do nothing.
• • • If none of the owners exist, requests the API server to delete the item.

###Propagator:

• The Propagator is for optimization, not for correctness.
• Consists of an Event Queue, a single worker, and a DAG of owner-dependent relations.
• • The DAG stores only name/uid/orphan triplets, not the entire body of every item.
• Watches for create/update/delete events for all resources, enqueues the events to the Event Queue.
• Worker:
• • Dequeues an item from the Event Queue.
• • If the item is an creation or update, then updates the DAG accordingly.
• • • If the object has an owner and the owner doesn’t exist in the DAG yet, then apart from adding the object to the DAG, also enqueues the object to the Dirty Queue.
• • • If the item is a deletion, then removes the object from the DAG, and enqueues all its dependent objects to the Dirty Queue.
• The propagator shouldn't need to do any RPCs, so a single worker should be sufficient. This makes locking easier.
• With the Propagator, we only need to run the Scanner when starting the GC to populate the DAG and the Dirty Queue.

###Finalizers:

• Like a controller, a finalizer is always running.
• A third party can develop and run their own finalizer in the cluster. A finalizer doesn't need to be registered with the API server.
• Watches for update events that meet two conditions:
• • the updated object has the identifier of the finalizer in ObjectMeta.Finalizers;
• • ObjectMeta.DeletionTimestamp is updated from nil to non-nil.
• Applies the finalizing logic to the object in the update event.
• After the finalizing logic is completed, removes itself from ObjectMeta.Finalizers.
• The API server deletes the object after the last finalizer removes itself from the ObjectMeta.Finalizers field.
• Because it's possible for the finalizing logic to be applied multiple times (e.g., the finalizer crashes after applying the finalizing logic but before being removed form ObjectMeta.Finalizers), the finalizing logic has to be idempotent.
• If a finalizer fails to act in a timely manner, users with proper privileges can manually remove the finalizer from ObjectMeta.Finalizers. We will provide a kubectl command to do this.

###the "orphan" finalizer:

• Watches for update events as described in "Finalizer" Chapter.
• Removes the object in the event from the OwnerReferences of its dependents.
• • dependent objects can be found via the DAG kept by the GC, or by relisting the dependent resource and checking the OwnerReferences field of each potential dependent object.
• Also removes any dangling owner references the dependent objects have.
• At last, removes the itself from the ObjectMeta.Finalizers of the object.

需要注意，想要启用该GC，需要在kube-apiserver和kube-controller-manager的启动参数中都设置--enable-garbage-collec为true。

接下来，我会单独写一篇文章，对kubernetes GC in v1.3进行源码分析。

本文转自开源中国-Kubernetes GC in v1.3