思索一个场景; 您在Kubernetes中创立了一个部署对象; 因此，它依据提供的清单生成正本集和pod。 后来，您看法到您错过了一个容器的属性，并且为了快速修复，您编辑了部署。 版本的部署会产生新的正本集对象和更新的Pod。 知道旧的会怎样吗? 异样，假设删除部署，正本集或Pod将会发作什么。 答案是不言而喻的。 删除部署将删除正本集和Pod; 否则，将会变得一团糟。
下面的陈述引出了一个更大的成绩：在Kubernetes中如何完成级联删除，能否有多种级联删除策略，在K8中能否能够存在孤立对象? 看起来这是典型的渣滓回收成绩。 这篇文章将讨论Kubernetes中渣滓搜集的概念和完成。 首先，让我们快速探求渣滓搜集。
什么是渣滓搜集(GC)?
简而言之，渣滓回收就是从系统中删除未运用的对象，并释放分配给它们的计算资源。 GC出如今一切初级编程言语中，而低级编程言语经过系统库具有GC。
GC的最常见算法之一是标记扫描。 我没有引见算法的详细信息，但是我们可以从标题有两个阶段的角度来解释它，在第一阶段中标记了在肃清阶段删除的对象。
> From Wikipedia
这是对GC的十分冗长的阐明，假设需求，请按照参考部分中发布的链接停止详细阐明。 如今，我们将讨论在K8s中完成GC的办法。
业主拥有; OwnerReference元数据
像面向对象的言语一样，某些对象援用其他对象/由其他对象组成，在Kubernetes中以相似的方式，某些对象拥有其他对象。 例如，正本集是一组Pod的一切者，而部署是正本集的一切者。
与面向对象的言语不同，在K8s对象清单定义中，我们历来没有明白定义或编写与一切者相关的关系，而是系统如何确定该关系? 在K8s中，每个附属对象都有一个独一的元数据字段称号metas.ownerReferences用于关系表示。
从Kubernetes 1.8末尾，K8为由特定控制器(例如ReplicaSet，StatefulSet，DaemonSet，Deployment，Job和CronJob)创立或采用的对象设置ownerReferences的值。
假设需求，还可以手动设置ownerReferences。
一个对象可以有多个ownerReferences，例如在称号空间中。
下面显示了Kind K8s独立群集上core-dns部署的metadata.ownerReferences值
假设细心看一下以上命令的输入，您会发现与其他GC完成的纤细差别。 对象关联参考金字塔是颠倒的，而不是常规的颠倒的。 下图将为您提供协助。
> Downside Up association of the objects in K8s
Kubernetes中的渣滓回收策略
如前所述，在Kubernetes 1.8之前，依赖对象删除逻辑的完成是在客户端，关于一些资源也是在控制器端。 客户端不是原子操作，有时中途失败会招致群集形状混乱，需求手动清算。 后来，为处置此成绩，K8s社区引入并完成了渣滓搜集器控制器，以更好，更复杂的方式处置GC。
在用于未运用对象GC的K8中，有两大类：
级联：在级联之一中，一切者的删除招致从群集中删除附属对象。
孤儿：望文生义，对一切者对象的删除操作只会将其从集群中删除，并使一切附属对象处于"孤儿"形状。
让我们深化了解上述策略。
在级联删除策略中，附属对象与一切者对象一同被删除。 在级联内，有两种形式：前景和背景。
前景级联删除：在前景策略中，一切者对象删除将不断等候，直到一切附属对象都被删除为止。 以后台删除是一切者对象形状更改为停止中的删除时，将发作第一个更改。 处于"正在删除"形状的对象的属性如下：
经过REST API，该对象依然可见
设置了对象的deleteTimestamp
对象的元数据.finalizers包含值" foregroundDeletion"。
一旦形状发作变化，渣滓搜集器将删除一切"阻塞"依赖项(拥有者参考.blockOwnerDeletion = true的对象)，最后删除拥有者对象。
背景级联删除：这要复杂得多，在这种状况下，它将直接删除一切者对象。 稍后，GC确定相关对象并将其从后台删除。 它比前台快得多，由于没有等候时间来删除附属对象。
在孤立策略中，将删除一切者对象，并将附属对象中的ownerReferences元数据设置为默许值。 之后，GC控制器确定孤立对象并将其删除。
Kubernetes渣滓搜集器控制器如何任务?
假设对象的OwnerReferences元数据中没有任何一切者对象，则GC控制器担任删除该对象。 GC控制器由扫描仪，渣滓处置器和传达器组成。
扫描顺序：运用发现API，它会检测K8s集群中支持的一切资源，并经过控制循环活期检测它，扫描系统中的一切资源，并将每个对象添加到"脏队列"中。
渣滓处置器：由在"脏队列"上任务的工人组成。 每个任务人员都会从"脏队列"中取出一个项目，并反省该项目的OwnerReferences能否为空。 假设为空，则仅从Dirty队列中取出下一个条目停止处置; 否则，反省OwnerReferences元数据中的每个条目。 假设OwnerReferences中列出的一切一切者均不存在，则任务顺序会央求API效劳器删除该对象。
传达器：传达器用于优化GC控制器，包含三个组件。 事情队列，单个任务顺序以及与一切者相关的关系的DAG。 以下是繁衍器的特性
DAG仅存储称号/ uid /孤立三元组，而不存储每个项目的整个主体。
监视一切资源的创立/更新/删除事情，并将事情排入事情队列。
任务者从事情队列中使项目出队。
K8s对象的创立或更新会相应地更新DAG。 假设资源具有一切者，但该一切者在DAG中尚不存在，则除了将对象添加到DAG之外，它还将对象排队到"脏队列"中。
删除K8s对象会将其从DAG中删除，并将其一切附属对象排队到"脏队列"中。
传达者不需求执行任何RPC，因此只需一个任务线程就足够了，并且锁定起来也更容易。
运用传达器，我们仅需在启动GC时运转扫描顺序以填充DAG和脏队列。
总体而言，Kubernetes中GC的完成是十分通用和复杂的，并且十分有效。 我希望这篇文章可以协助您了解K8s中GC的见地。 感谢您的阅读和等候反应或赞赏。
【编辑引荐】
要成为一名成功的开发人员，您应该保持的22件事
2020年开发运维工具清单：选择开发运维工具堆栈吧
Kubernetes容器网络模型
你必须知道的6款Web开发工具
每个开发人员都应该了解这些术语中更深的纤细差别
(责任编辑：admin)