kubernetes: gc's behavior is not consistent when restarting kube-controller-manager
What happened: Say there’s a CR named MyTest and Pod is the owner of the MyTest object. If setting apiVersion/kind to MyTest by mistake and setting name/uid in ownerReferences correctly, kube-controller-manager wont’ gc MyTest object. But when restarting kube-controller-manager, it will gc MyTest objects in some situations and in other situations it wont’ gc MyTest objects.
The MyTest object by mistake is like the following:
apiVersion: test/v1
kind: MyTest
metadata:
....
ownerReferences:
- apiVersion: test/v1 # It should be apiVersion of Pod
blockOwnerDeletion: true
controller: true
kind: MyTest # It should be kind of Pod
name: <Pod Name>
uid: <Pod UID>
What you expected to happen:
The gc behavior should be consistent in the following situations:
- When kube-controller-manager is running, create MyTest object and set its ownerReference to a Pod but set apiVersion/kind to MyTest by mistake and setting name/uid correctly. kube-controller-manager should garbage collect MyTest but in reality it didn’t
- When kube-controller-manager is restarting, the above MyTest objects should be garbage collected or shouldn’t be garbage collected determinately. In reality, the result is not determinate
How to reproduce it (as minimally and precisely as possible):
- Create a CRD
- Create a Pod
- Create a CR object. Set apiVersion/kind to the CR’s and set name/uid to the Pod’s.
- Observe whether the CR object could be garbage collected when kube-controller-manager is running
- Restart kube-controller-manager and observe whether CR object will be garbage collected (this situation may need to be repeated sometimes because the result is dependent on the completion order of Pod/MyTest in concurrentUIDToNode)
Anything else we need to know?:
It may be better to use <apiVersion, kind, group, uid> as the key of uidToNode to make the judgement condition of gc more consistent.
Environment:
- Kubernetes version (use
kubectl version): v1.11.2 - Cloud provider or hardware configuration:
- OS (e.g. from /etc/os-release):
- Kernel (e.g.
uname -a): - Install tools:
- Others:
/kind bug
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 17 (11 by maintainers)
Immediate response could help developers find errors more quickly than delayed and indeterminate response.