Closed chaunceyjiang closed 8 months ago
Did you use an orphan deletion strategy?
Did you use an orphan deletion strategy?
This is my code for deleting a job.
Are you still able to reproduce this problem? I can't reproduce it. Only when I use an orphan deletion strategy, the phenomenon that occurs is consistent with the issue description.
Since this field ownerReferences
has been removed from the resourcebinding object, that proves that the garbage collector has worked. But the resourcebinding object still exists, which looks like an orphan deletion strategy was used.
This is my code for deleting a job.
From your code, you are not using orphan deletion strategy. So we’d better take a look at the detailed audit log of the deleted Job.
Since this field ownerReferences has been removed from the resourcebinding object,
Yes.
which looks like an orphan deletion strategy was used.
I don't really understand the orphan deletion strategy
. I noticed the generation
changed from 3
to 4
. I feel like the GC isn't working properly. It seems the 'ownerReferences' were accidentally deleted.
I feel like the GC isn't working properly. It seems the 'ownerReferences' were accidentally deleted.
Maybe, but it has nothing to do with Karmada.
Looks similar to https://github.com/karmada-io/karmada/issues/969 @chaunceyjiang
try delete job with background
@yanfeng1992 Thanks for the reminder, I'll go check this out https://github.com/karmada-io/karmada/issues/969.
@yanfeng1992 @whitewindmills Thank you all, the problem has been resolved. It indeed was the situation as you described.
What happened:
The resourcebinding of the job has not been deleted.
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
The
delete
event seems to have triggered rematching policies. ownerReferences has been removedEnvironment:
kubectl-karmada version
orkarmadactl version
):