K8s GC设计原则

本文深入探讨了Kubernetes中的垃圾回收(GC)机制,包括它如何通过Garbage Collector和ownerReferences实现资源对象的清理。K8s采用级联删除策略,通过扫描和事件监听来检测废弃资源。此外,还介绍了Finalizer如何用于在删除owner资源时保留dependents。文章揭示了GC的工作流程、潜在的Race问题及其解决方案,以及在资源管理中的作用。
摘要由CSDN通过智能技术生成

 GC 是 Garbage Collector 的简称。从功能层面上来说,它和编程语言当中的「GC」 基本上是一样的。它清理 Kubernetes 中「符合特定条件」的 Resource Object。(在 k8s 中,你可以认为万物皆资源,很多逻辑的操作对象都是 Resource Object。)

Q: What are dependent mechanisms to clear needless resource objects?

  Kubernetes 在不同的 Resource Objects 中维护一定的「从属关系」。内置的 Resource Objects 一般会默认在一个 Resource Object 和它的创建者之间建立一个「从属关系」。

  当然,你也可以利用 ObjectMeta.OwnerReferences 自由的去给两个 Resource Object 建立关系,前提是被建立关系的两个对象必须在一个 Namespace 下。

 1 // OwnerReference contains enough information to let you identify an owning
 2 // object. Currently, an owning object must be in the same namespace, so there
 3 // is no namespace field.
 4 type OwnerReference struct {
 5     // API version of the referent.
 6     APIVersion string `json:"apiVersion" protobuf:"bytes,5,opt,name=apiVersion"`
 7     // Kind of the referent.
 8     // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds
 9     Kind string `json:"kind" protobuf:"bytes,1,opt,name=kind"`
10     // Name of the referent.
11     // More info: http://kubernetes.io/docs/user-guide/identifiers#names
12     Name string `json:"name" protobuf:"bytes,3,opt,name=name"`
13     // UID of the referent.
14     // More info: http://kubernetes.io/docs/user-guide/identifiers#uids
15     UID types.UID `json:"uid" protobuf:"bytes,4,opt,name=uid,casttype=k8s.io/apimachinery/pkg/types.UID"`
16     // If true, this reference points to the managing controller.
17     // +optional
18     Controller *bool `json:"controller,omitempty" protobuf:"varint,6,opt,name=controller"`
19     // If true, AND if the owner has the "foregroundDeletion" finalizer, then
20     // the owner cannot be deleted from the key-value store until this
21     // reference is removed.
22     // Defaults to false.
23     // To set this field, a user needs "delete" permission of the owner,
24     // otherwise 422 (Unprocessable Entity) will be returned.
25     // +optional
26     BlockOwnerDeletion *bool `json:"blockOwnerDeletion,omitempty" protobuf:"varint,7,opt,name=blockOwnerDeletion"`
27 }

   OwnerReference 一般存在于某一个 Resource Object 信息中的 metadata 部分。

   OwnerReference 中的字段可以唯一的确定 k8s 中的一个 Resource Object。两个 Object 可以通过这种方式建立一个 owner-dependent 的关系。

  K8s 实现了一种「Cascading deletion」(级联删除)的机制,它利用已经建立的「从属关系」进行资源对象的清理工作。例如,当一个 dependent 资源的 owner 已经被删除或者不存在的时候,从某种角度就可以判定,这个 dependent 的对象已经是异常(无人管辖)的了,需要进行清理。而 「cascading deletion」则是被 k8s 中的一个 controller 组件实现的: Garbage Collector 

  所以,k8s 是通过 Garbage Collector 和 ownerReference 一起配合实现了「垃圾回收」的功能。

Q: What is the relationship like ?(owner-dependent)

  我们可以通过一个实际的例子来了解这个「从属关系」:

 1 apiVersion: extensions/v1beta1
 2 kind: ReplicaSet
 3 metadata:
 4   annotations:
 5     deployment.kubernetes.io/desired-replicas: "2"
 6     deployment.kubernetes.io/max-replicas: "3"
 7     deployment.kubernetes.io/revision: "1"
 8   creationTimestamp: 2018-09-07T07:11:52Z
 9   generation: 1
10   labels:
11     app: coffee
12     pod-template-hash: "3866135192"
13   name: coffee-7dbb5795f6
14   namespace: default
15   ownerReferences:
16   - apiVersion: apps/v1
17     blockOwnerDeletion: true
18     controller: true
19     kind: Deployment
20     name: coffee
21     uid: 4b807ee6-b26d-11e8-b891-fa163eebca40
22   resourceVersion: "476159"
23   selfLink: /apis/extensions/v1beta1/namespaces/default/replicasets/coffee-7dbb5795f6
24   uid: 4b81e76c-b26d-11e8-b891-fa163eebca40
25 spec:
26   replicas: 2
27 ....

  上面截取了一个 ReplicaSet Object 中的 metadata 的部分信息。

  我们可以注意到,它的 ownerReferences 字段标识了一个 Deployment Object。我们都清楚的是,ReplicaSet 会创建一系列的 Pod。通过 spec.replicas:2 可以知道,他会创建两个pod。

1 root@xr-service-mesh-lab:~/is
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值