-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Description
Which component are you using?:
/area cluster-autoscaler
Is your feature request designed to solve a problem? If so describe the problem this feature should solve.:
Cluster Autoscaler currently identifies "startup taints" (temporary taints removed after node initialization) using either a hardcoded internal prefix or explicit enumeration of full taint keys via the --startup-taint flag.
This model is is inflexible for frameworks like node-readiness-controller that manage multiple readiness taints for different node bootstrapping requirements. These taints by intent are all short-lived as they'll be removed by the controller after their node conditions are ready, and by design they all share a common unique prefix: readiness.k8s.io/.
Describe the solution you'd like.:
Introduce a new configuration flag, --startup-taint-prefix allowing users to define their own custom prefix. Any node taint matching these prefixes would be treated as a startup-taint. This would greatly improve the ergonomics of working both cluster-autoscaler and node-readiness-controller together in a cluster, as admins dont need to revise and restart CA with every new change in readiness (taint) requirement coming later in the cluster.
Describe any alternative solutions you've considered.:
- hardcoding specific prefixes (eg: readiness.k8s.io/ ) in the cluster-autoscaler source code. This will help the immediate integration need for NRC. however, this approach is not generic and would require changes in the future for every new readiness framework or third-party tool.
- explicitly enumerating every potential taint key using the existing
--startup-taintflag. This is the current workaround but prone to disruptions in dynamic environments as it requires admins to update config and restart CA for any updates.
Additional context.: