垃圾回收器
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 集群健康运行的重要步骤之一。
