Kubernetes GC in v1.3

本文是对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进行源码分析。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

10g升级至11g需要考虑的参数优化(29天)

10g升级至11g除了需要做一个详尽的计划, 需要采集10g系统的负载情况,做一个整体的把握,在升级之后,再做负载分析。 保证不会出现大的问题,sql的执行计划...

36550
来自专栏PPV课数据科学社区

【学习】七天搞定SAS(一):数据的导入、数据结构

SAS的数据类型 ? 首先,sas的编程大概就两块:Data和PROC,这个倒是蛮清晰的划分。然后目前关注data部分。 SAS的数据类型还真的只有两种:数字和...

416120
来自专栏游戏杂谈

cocos2d-x 2.x版本接入bugly的总结

最开始项目使用的是自己DIY的很简陋的上报系统,后来改成google breakpad来上报,发现其实都做的不太理想,游戏引擎因为版本历史问题存在一些崩溃问题。...

20900
来自专栏HansBug's Lab

1455: 罗马游戏

1455: 罗马游戏 Time Limit: 5 Sec  Memory Limit: 64 MB Submit: 721  Solved: 272 [Subm...

315100
来自专栏小勇DW3

生产环境下JVM调优参数的设置实例

◆ NewSize较大,old gen 剩余空间64m,一方面可能会带来old区容易增长到报警范围(监控数据显示oldgenused长期在50m左右,接近78%...

28160
来自专栏游戏杂谈

基于SOUI开发一个简单的小工具

Duilib 很久不维护了,而很多不同的分支,似乎都不太维护。微信 Windows 的版本是基于 Duilib 进行开发的,说明应该还是很广泛的。

46330
来自专栏运维

DELL R710 服务器内存排错

man dmidecode 可以得到详细的介绍和使用方法,dmidecode - DMI table decoder,DMI (Desktop Manageme...

43420
来自专栏Golang语言社区

Golang生产级可靠UDP库

kcp-go is a Production-Grade Reliable-UDP library for golang.

83320
来自专栏菩提树下的杨过

ExtJs学习笔记(3)_GridPanel[XML做数据源]

这一节,将学习到除了用JSON做GridPanel的数据源外,还可以使用XML 一。静态示例 1.xml文件内容: <?xml version="1.0...

23880
来自专栏菩提树下的杨过

Silverlight Telerik控件学习:GridView双向绑定

做过WinForm数据库开发的人,一定有类似经历:DataGrid绑定后,如果允许行编辑,数据一顿修改后,想批量保存修改后的结果,通常是将DataGrid的所有...

23850

扫码关注云+社区

领取腾讯云代金券