[YUNIKORN-1627] Admission controller triggers infinite recreation of ReplicaSet objects

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 1.2.0
• Fix Version/s: 1.3.0
• Component/s: shim - kubernetes
• Labels: pull-request-available
• Target Version: 1.3.0
• Assignee: Peter Bacsko
• Reporter: Craig Condit
• Created: 10/Mar/23 18:12
• Updated: 20/Jun/23 14:41
• Resolved: 20/Mar/23 22:08

Description

YUNIKORN-1338 added support in the admission controller for mutating workload objects other than Pods for the purposes of user tracking (and eventual enforcement). This functionality works as designed.

However, in the case where a ReplicaSet is managed by a Deployment, the changes to the ReplicaSet pod template trigger the associated Deployment to recreate the ReplicaSet without the changes, which the admission controller then updates, triggering another ReplicaSet, etc. ad infinitum. 

The workaround for now is to set the following in the yunikorn-configs ConfigMap, which disables the functionality:

admissionController.accessControl.bypassAuth: "true"

The real fix needs to take into account any ownerReference in a workload which points to another workload type that we manage. This definitely includes ReplicaSet -> Deployment, but could include other workload relationships (more investigation needed on this).

For ReplicaSets, if the ownerReference is set to a Deployment, it should be sufficient to check for that and assume that the Deployment itself has passed in the appropriate user information due to the admission controller having mutated the Deployment.

Issue Links

• is caused by: YUNIKORN-1338 [admission] support different kind of workloads other than pods
• links to: GitHub Pull Request #552