垃圾回收器

Kubernetes 提供了兩種垃圾回收器：基于 API 服務器的垃圾回收器和基于控制器的垃圾回收器。

基于 API 服務器的垃圾回收器

基于 API 服務器的垃圾回收器在 API 服務器端運行，它依賴于 API 對象的 metadata.ownerReferences 字段來識別孤兒資源。當一個資源的擁有者被刪除時，垃圾回收器會檢查該資源的 metadata.ownerReferences 字段，并根據回收策略（Foreground 或 Background）來決定是否刪除該孤兒資源。

Foreground 回收策略會阻塞刪除擁有者的操作，直到孤兒資源也被刪除。而 Background 回收策略則允許刪除擁有者的操作立即完成，但垃圾回收器會在后臺異步地刪除孤兒資源。

基于控制器的垃圾回收器

基于控制器的垃圾回收器通常是由特定的控制器實現的，如 ReplicaSet 或 DaemonSet 控制器。這些控制器會管理它們所擁有的 Pod，并在必要時創建或刪除 Pod。當控制器檢測到它擁有的某個 Pod 不再需要時（例如，ReplicaSet 的副本數減少），它會觸發垃圾回收機制來刪除該 Pod。

孤兒資源的處理

當一個資源的擁有者被刪除時，該資源就變成了孤兒資源。Kubernetes 提供了兩種處理孤兒資源的方式：級聯刪除（Cascading Deletion）和孤立刪除（Orphaning）。

級聯刪除

級聯刪除是指當擁有者被刪除時，其所有孤兒資源也會被自動刪除。這可以通過在擁有者的 metadata.ownerReferences 字段中設置 blockOwnerDeletion 為 true 來實現。當 blockOwnerDeletion 為 true 時，擁有者資源不能被刪除，除非其所有孤兒資源都已經被刪除或級聯刪除。

孤立刪除

孤立刪除是指當擁有者被刪除時，其孤兒資源不會被自動刪除，而是被標記為孤兒狀態。這可以通過在擁有者的 metadata.ownerReferences 字段中設置 blockOwnerDeletion 為 false 或不設置該字段來實現。在這種情況下，孤兒資源將不再受擁有者的控制，但仍然存在于集群中，需要管理員手動處理。

回收策略的選擇

選擇適合的回收策略取決于具體的場景和需求。Foreground 回收策略適用于那些需要確保孤兒資源在擁有者被刪除之前也被刪除的場景，以確保資源的一致性和完整性。而 Background 回收策略則適用于那些對孤兒資源的刪除順序不太關心的場景，可以提高系統的響應速度和吞吐量。

需要注意的是，在使用垃圾回收機制時，管理員應該謹慎處理孤兒資源，確保它們不會占用過多的集群資源或導致其他問題。定期檢查和清理孤兒資源是保持 Kubernetes 集群健康運行的重要步驟之一。