考慮一個(gè)場(chǎng)景; 您在Kubernetes中創(chuàng)建了一個(gè)部署對(duì)象; 因此，它根據(jù)提供的清單生成副本集和pod。 后來，您意識(shí)到您錯(cuò)過了一個(gè)容器的屬性，并且為了快速修復(fù)，您編輯了部署。 版本的部署會(huì)產(chǎn)生新的副本集對(duì)象和更新的Pod。 知道舊的會(huì)怎樣嗎? 同樣，如果刪除部署，副本集或Pod將會(huì)發(fā)生什么。 答案是顯而易見的。 刪除部署將刪除副本集和Pod; 否則，將會(huì)變得一團(tuán)糟。

上面的陳述引出了一個(gè)更大的問題：在Kubernetes中如何實(shí)現(xiàn)級(jí)聯(lián)刪除，是否有多種級(jí)聯(lián)刪除策略，在K8中是否可能存在孤立對(duì)象? 看起來這是典型的垃圾回收問題。 這篇文章將討論Kubernetes中垃圾收集的概念和實(shí)現(xiàn)。 首先，讓我們快速探索垃圾收集。

什么是垃圾收集(GC)?

簡(jiǎn)而言之，垃圾回收就是從系統(tǒng)中刪除未使用的對(duì)象，并釋放分配給它們的計(jì)算資源。 GC出現(xiàn)在所有高級(jí)編程語言中，而低級(jí)編程語言通過系統(tǒng)庫具有GC。

GC的最常見算法之一是標(biāo)記掃描。 我沒有介紹算法的詳細(xì)信息，但是我們可以從標(biāo)題有兩個(gè)階段的角度來解釋它，在第一階段中標(biāo)記了在清除階段刪除的對(duì)象。

> From Wikipedia

這是對(duì)GC的非常簡(jiǎn)短的說明，如果需要，請(qǐng)按照參考部分中發(fā)布的鏈接進(jìn)行詳細(xì)說明。 現(xiàn)在，我們將探討在K8s中實(shí)現(xiàn)GC的方法。

業(yè)主擁有; OwnerReference元數(shù)據(jù)

像面向?qū)ο蟮恼Z言一樣，某些對(duì)象引用其他對(duì)象/由其他對(duì)象組成，在Kubernetes中以類似的方式，某些對(duì)象擁有其他對(duì)象。 例如，副本集是一組Pod的所有者，而部署是副本集的所有者。

與面向?qū)ο蟮恼Z言不同，在K8s對(duì)象清單定義中，我們從來沒有明確定義或編寫與所有者相關(guān)的關(guān)系，而是系統(tǒng)如何確定該關(guān)系? 在K8s中，每個(gè)從屬對(duì)象都有一個(gè)唯一的元數(shù)據(jù)字段名稱metas.ownerReferences用于關(guān)系表示。

• 從Kubernetes 1.8開始，K8為由特定控制器(例如ReplicaSet，StatefulSet，DaemonSet，Deployment，Job和CronJob)創(chuàng)建或采用的對(duì)象設(shè)置ownerReferences的值。
• 如果需要，還可以手動(dòng)設(shè)置ownerReferences。
• 一個(gè)對(duì)象可以有多個(gè)ownerReferences，例如在名稱空間中。

下面顯示了Kind K8s獨(dú)立群集上core-dns部署的metadata.ownerReferences值

如果仔細(xì)看一下以上命令的輸出，您會(huì)發(fā)現(xiàn)與其他GC實(shí)現(xiàn)的細(xì)微差別。 對(duì)象關(guān)聯(lián)參考金字塔是顛倒的，而不是常規(guī)的顛倒的。 下圖將為您提供幫助。

> Downside Up association of the objects in K8s

Kubernetes中的垃圾回收策略

如前所述，在Kubernetes 1.8之前，依賴對(duì)象刪除邏輯的實(shí)現(xiàn)是在客戶端，對(duì)于一些資源也是在控制器端。 客戶端不是原子操作，有時(shí)中途失敗會(huì)導(dǎo)致群集狀態(tài)混亂，需要手動(dòng)清理。 后來，為解決此問題，K8s社區(qū)引入并實(shí)現(xiàn)了垃圾收集器控制器，以更好，更簡(jiǎn)單的方式處理GC。

在用于未使用對(duì)象GC的K8中，有兩大類：

• 級(jí)聯(lián)：在級(jí)聯(lián)之一中，所有者的刪除導(dǎo)致從群集中刪除從屬對(duì)象。
• 孤兒：顧名思義，對(duì)所有者對(duì)象的刪除操作只會(huì)將其從集群中刪除，并使所有從屬對(duì)象處于"孤兒"狀態(tài)。

讓我們深入了解上述策略。

在級(jí)聯(lián)刪除策略中，從屬對(duì)象與所有者對(duì)象一起被刪除。 在級(jí)聯(lián)內(nèi)，有兩種模式：前景和背景。

前景級(jí)聯(lián)刪除：在前景策略中，所有者對(duì)象刪除將一直等待，直到所有從屬對(duì)象都被刪除為止。 當(dāng)前臺(tái)刪除是所有者對(duì)象狀態(tài)更改為進(jìn)行中的刪除時(shí)，將發(fā)生第一個(gè)更改。 處于"正在刪除"狀態(tài)的對(duì)象的屬性如下：

• 通過REST API，該對(duì)象仍然可見
• 設(shè)置了對(duì)象的deleteTimestamp
• 對(duì)象的元數(shù)據(jù).finalizers包含值" foregroundDeletion"。

一旦狀態(tài)發(fā)生變化，垃圾收集器將刪除所有"阻塞"依賴項(xiàng)(擁有者參考.blockOwnerDeletion = true的對(duì)象)，最后刪除擁有者對(duì)象。

背景級(jí)聯(lián)刪除：這要簡(jiǎn)單得多，在這種情況下，它將直接刪除所有者對(duì)象。 稍后，GC確定相關(guān)對(duì)象并將其從后臺(tái)刪除。 它比前臺(tái)快得多，因?yàn)闆]有等待時(shí)間來刪除從屬對(duì)象。

在孤立策略中，將刪除所有者對(duì)象，并將從屬對(duì)象中的ownerReferences元數(shù)據(jù)設(shè)置為默認(rèn)值。 之后，GC控制器確定孤立對(duì)象并將其刪除。

Kubernetes垃圾收集器控制器如何工作?

如果對(duì)象的OwnerReferences元數(shù)據(jù)中沒有任何所有者對(duì)象，則GC控制器負(fù)責(zé)刪除該對(duì)象。 GC控制器由掃描儀，垃圾處理器和傳播器組成。

掃描程序：使用發(fā)現(xiàn)API，它會(huì)檢測(cè)K8s集群中支持的所有資源，并通過控制循環(huán)定期檢測(cè)它，掃描系統(tǒng)中的所有資源，并將每個(gè)對(duì)象添加到"臟隊(duì)列"中。

垃圾處理器：由在"臟隊(duì)列"上工作的工人組成。 每個(gè)工作人員都會(huì)從"臟隊(duì)列"中取出一個(gè)項(xiàng)目，并檢查該項(xiàng)目的OwnerReferences是否為空。 如果為空，則僅從Dirty隊(duì)列中取出下一個(gè)條目進(jìn)行處理; 否則，檢查OwnerReferences元數(shù)據(jù)中的每個(gè)條目。 如果OwnerReferences中列出的所有所有者均不存在，則工作程序會(huì)請(qǐng)求API服務(wù)器刪除該對(duì)象。

傳播器：傳播器用于優(yōu)化GC控制器，包含三個(gè)組件。 事件隊(duì)列，單個(gè)工作程序以及與所有者相關(guān)的關(guān)系的DAG。 以下是繁殖器的特性

• DAG僅存儲(chǔ)名稱/ uid /孤立三元組，而不存儲(chǔ)每個(gè)項(xiàng)目的整個(gè)主體。
• 監(jiān)視所有資源的創(chuàng)建/更新/刪除事件，并將事件排入事件隊(duì)列。
• 工作者從事件隊(duì)列中使項(xiàng)目出隊(duì)。
• K8s對(duì)象的創(chuàng)建或更新會(huì)相應(yīng)地更新DAG。 如果資源具有所有者，但該所有者在DAG中尚不存在，則除了將對(duì)象添加到DAG之外，它還將對(duì)象排隊(duì)到"臟隊(duì)列"中。
• 刪除K8s對(duì)象會(huì)將其從DAG中刪除，并將其所有從屬對(duì)象排隊(duì)到"臟隊(duì)列"中。
• 傳播者不需要執(zhí)行任何RPC，因此只需一個(gè)工作線程就足夠了，并且鎖定起來也更容易。
• 使用傳播器，我們僅需在啟動(dòng)GC時(shí)運(yùn)行掃描程序以填充DAG和臟隊(duì)列。

總體而言，Kubernetes中GC的實(shí)現(xiàn)是非常通用和復(fù)雜的，并且非常有效。 我希望這篇文章可以幫助您了解K8s中GC的見解。 感謝您的閱讀和期待反饋或贊賞。