What happened:
Define a Job which has a selector for labels of Pod.
Define a Cluster or Namespace scoped PodScheduling policy using Kupid which works on the same labels which satisfies the Pod created by the above Job definition.
Once the Job has completed, change the PodScheduling policy by changing the label selector.
Try to delete the Job created before the PodScheduling policy was changed.
Once the new policy comes into affect, it stops the existing job to be deleted as it will try to update the PodSpec with the new Labels which is an immutable field.
We see following errors in KCM logs
I1207 11:25:10.408731 1 garbagecollector.go:529] remove DeleteDependents finalizer for item [batch/v1/Job, namespace: shoot--dev--test-ash-3, name: a3fc17-compact-job, uid: 728ec193-2a8e-4f8a-befb-1fa9526ef7f8]
E1207 11:25:10.431940 1 garbagecollector.go:309] error syncing item &garbagecollector.node{identity:garbagecollector.objectReference{OwnerReference:v1.OwnerReference{APIVersion:"batch/v1", Kind:"Job", Name:"a3fc17-compact-job", UID:"728ec193-2a8e-4f8a-befb-1fa9526ef7f8",
BlockOwnerDeletion:(*bool)(0xc001d277fa)}}}: Job.batch "a3fc17-compact-job" is invalid: spec.template: Invalid value: core.PodTemplateSpec: field is immutable
This keep the job orphaned unless manually deleted.
What you expected to happen:
Kupid should not update the spec of a Job as it runs to completion.
How to reproduce it (as minimally and precisely as possible):
Follow the steps above.
Anything else we need to know:
This happens only where the earlier Job is not deleted before creating the change in the PodScheduling Policy.
What happened: Define a Job which has a selector for labels of Pod. Define a Cluster or Namespace scoped PodScheduling policy using Kupid which works on the same labels which satisfies the Pod created by the above Job definition.
Once the Job has completed, change the PodScheduling policy by changing the label selector. Try to delete the Job created before the PodScheduling policy was changed. Once the new policy comes into affect, it stops the existing job to be deleted as it will try to update the PodSpec with the new Labels which is an immutable field. We see following errors in KCM logs
This keep the job orphaned unless manually deleted.
What you expected to happen: Kupid should not update the spec of a Job as it runs to completion.
How to reproduce it (as minimally and precisely as possible): Follow the steps above.
Anything else we need to know: This happens only where the earlier Job is not deleted before creating the change in the PodScheduling Policy.
Environment: k8s -
v1.19.5kupid -v0.1.6