走读代码对 获取 deployment 相关事件 功能的疑问

[twgcode]

疑问1

在 pkg/platform/proxy/apps/deployment/storage/event.go 文件中的 listEventsByApps 函数, 获取 ReplicaSet 管理的 Pod 时，为什么要这么写

为啥要在 for循环中 判断 当前 ReplicaSet 的每个 OwnerReferences， 然后只要每个符合 当前 deployment 要求的 OwnerReference 都会 获取 请求 api server 都会 获取一次 Pod 列表。难道 一个 ReplicaSet 会属于 一个 deployment 2次？如果不是的话 是不是代码可以把这个for循环去掉

疑问2

判断 rs 是不是 属于 deployment 的时候 是不是用 references.UID != deployment.UID 比 references.Name != name 要好一点

[leoryu]

For question 1: Generally, a resource will only have one OwnerReference, but sometimes, a resource may be dependent on multiple resources. In this case, you can use multiple OwnerReferences to record the dependency relationship of this resource. Although there is no multiple dependency relationship between RS and Deploy at the current stage, this writing can cover more possibilities in the future, so I think this is no problem.

For question 2: For many resources, if we changed label/anno, the UID will be changed. I'm not sure wehter the deploy has this feature or not, but using name will not lose the events if UID is changed.

[twgcode]

question 2: Modifying the labels and annotations of a Deployment does not cause a change in the Deployment's UID. According to the design theory of Kubernetes, the UID only changes when the resource is recreated. However, it is true that querying by the same Name can retrieve "additional" events. From the perspective of retrieving "additional" events, this reasoning is indeed correct.

对于 Deployment 的 labels 和 annotations 的修改 不会导致 Deployment uid 发送变化，按照 k8s 的设计理论上只有 资源发送重建时 uid 才会变化。但是同 Name 判断确实可以查询到 “更多” 的事件，从获取“更多”的事件角度考虑 这样确实没错。