It looks like cfg.ApiServer.FeatureGates is currently not used when constructing kube-apiserver arguments.
In pkg/controllers/kube-apiserver.go, feature gates are hardcoded in the APIServerArguments map instead of being derived from the config.
I’d like to update this so that feature gates are built dynamically from cfg.ApiServer.FeatureGates (e.g. enabled → Feature=true, disabled → Feature=false) and passed via the existing feature-gates argument.
If no feature gates are specified in the config, the existing defaults would be preserved to avoid changing current behavior.
Does this approach align with the intended design?
It looks like
cfg.ApiServer.FeatureGatesis currently not used when constructing kube-apiserver arguments.In
pkg/controllers/kube-apiserver.go, feature gates are hardcoded in theAPIServerArgumentsmap instead of being derived from the config.I’d like to update this so that feature gates are built dynamically from
cfg.ApiServer.FeatureGates(e.g. enabled →Feature=true, disabled →Feature=false) and passed via the existingfeature-gatesargument.If no feature gates are specified in the config, the existing defaults would be preserved to avoid changing current behavior.
Does this approach align with the intended design?