我试图追查为什么我们所有的子 pod 在调用 helm delete 后偶尔会保留在 kubernetes 中。请注意，这是间歇性的，通常情况下一切正常，我们尚未确定如何可靠地重新创建孤立的 pod。
在一些逻辑追踪之后，我们认为我们将问题追踪到子部署的 ownerReference 是错误的。作为记录，子项和父项都是具有指向单个正在运行的 pod 的单个副本集的部署。
在子部署的 ownerReference 中，它有一个引用父部署的 uid，但它有一种 pod 而不是部署。这似乎是错误的，所以我们改变了我们以编程方式设置种类的地方，说部署而不是 pod。奇怪的是，这导致我们的 rancher 失败，子部署根本不再出现在 rancher 中。
编辑： 在使用正确类型进行进一步实验后，如果我转到资源->工作负载并按工作负载或工作负载/命名空间选项使用组，则部署不会显示在 rancer 中，Pod 将与其他两个排序选项一起显示。如果我手动转到部署的适当 URL，它将打开工作负载，只是出于某种原因它没有列为资源中的选项。
很明显 ownerReference 和 kind 在某种程度上与我假设的不同，因为我认为有一个与 UID 指向的资源不同的 kind 会导致删除失败，我不会想改变 kind我认为正确的价值会破坏牧场主。
谁能解释一下 ownerReference 是怎么回事，kind 和 UID 的真正含义是什么，kind 是否应该与 UID 的资源类型相匹配？我试过检查文档，但它没有定义 kind 值真正代表什么。
在Kubernetes中，ownerReference字段用于建立资源之间的父子关系。它允许 Kubernetes 跟踪哪个资源拥有其他资源，并在删除父资源时删除子资源。
ownerReference字段包含两个重要的信息：拥有资源的UID，以及拥有资源的种类。 UID 是拥有资源的唯一标识符，而 kind 表示拥有资源的类型（例如 Deployment、StatefulSet 等）。
kind 字段用于帮助Kubernetes 了解什么样的资源是子资源的所有者。如果种类不正确或与拥有资源的实际种类不匹配，可能会导致您遇到的问题。
当您将种类设置为“pod”而不是“部署”时，会导致 Rancher 失败，因为它无法在其 UI 中正确显示子部署。这是因为 Rancher 期望部署成为子资源的所有者，而不是 pod。
所以，为了回答你的问题，ownerReference 中的种类应该与拥有资源的实际种类相匹配。如果不匹配，可能会导致您遇到的问题。此外，当您解决此类问题时，了解 ownerReference 字段的工作原理以及 Kubernetes 和其他工具如何使用它非常重要。