Problem to Solve
In a platform context KubeDownscaler is generally handled by cluster admins and so the uptime/downtime scheduling. Developers may discover how KubeDownscaler works and bypass the schedule by applying exclude or other annotations to override the global schedule at workload level (recently found out a case inside one of my environments)
Proposal
Implement a logic to block/mutate annotations, this can be done through:
- Our Admission Controller
- Kubernetes Native CRDs: Mutating Admission Policy, Mutating Admission Policy Binding (beta from v1.34), Validating Admission Policy, Validating Admission Policy Binding (stable from v.1.30)
GoKubeDownscaler/GoKubeDownscalerWebhook Service Accounts must be excluded from this, as well as other Service Accounts specified from the user (i.e Service Accounts dedicated to cicd pipelines or other robot users)
I would go for solution 2, since we wouldn't need to mantain any code for that. I would leave the admission controller for complex features only
Who Can Address the Issue
Other Links/References
Problem to Solve
In a platform context KubeDownscaler is generally handled by cluster admins and so the uptime/downtime scheduling. Developers may discover how KubeDownscaler works and bypass the schedule by applying exclude or other annotations to override the global schedule at workload level (recently found out a case inside one of my environments)
Proposal
Implement a logic to block/mutate annotations, this can be done through:
GoKubeDownscaler/GoKubeDownscalerWebhook Service Accounts must be excluded from this, as well as other Service Accounts specified from the user (i.e Service Accounts dedicated to cicd pipelines or other robot users)
I would go for solution 2, since we wouldn't need to mantain any code for that. I would leave the admission controller for complex features only
Who Can Address the Issue
Other Links/References