Kubelet config: Validate new config against future feature gates

[mtaufen]

This fixes an issue with KubeletConfiguration validation, where the
feature gates set by the new config were not taken into account.

Also fixes a validation issue with dynamic Kubelet config, where flag
precedence was not enforced prior to dynamic config validation in the
controller; this prevented rejection of dynamic configs that don't merge
well with values set via legacy flags.

Fixes #63305

NONE

[mtaufen]

I'm not 100% sure if this is the pattern I want, because it looks like a generic utility but we have a very specific use-case: enforce flag precedence so the final config combination is validated before choosing a config.

At the very least, we should warn people in a comment, and maybe change the name to something less generic.

[dashpole]

Alternatively, we could make it something generic, and use it in the e2e tests. https://github.com/kubernetes/kubernetes/blob/master/test/e2e_node/util.go#L106 is essentially the same function.

[mtaufen]

It's more about how it's used in the controller; it's an extension point that we only want to use as a last resort.

[mtaufen]

Though I don't see how we get away from it as long as we have to enforce flag precedence.

[mtaufen]

I think we'll go with this for now. I added a warning to the comment above the field on the controller and to the NewController constructor.

[k8s-github-robot]

[MILESTONENOTIFIER] Milestone Pull Request: Up-to-date for process

@dashpole @dchen1107 @liggitt @mtaufen

Pull Request Labels

• sig/cluster-lifecycle sig/node: Pull Request will be escalated to these SIGs if needed.
• priority/important-soon: Escalate to the pull request owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.
• kind/feature: New functionality.

Help

• Additional instructions
• Commands for setting labels

[liggitt]

why are we starting with a copy of the global gates? wouldn't kc.FeatureGates be the merged args+config at this point?

edit: hmm, because we don't want to overwrite the global here, and don't have a good way to construct a new default one from scratch

[mtaufen]

yup, exactly

[mtaufen]

TODO: After this merges, double check validation in case concurrent PRs add more feature gate checks (e.g. #63912).

[dashpole]

/lgtm
I like all of the warning comments.
Just because I am curious, do we plan to deprecate the feature gates flag in favor of including it in the component configuration? Will we be able to remove the TransformFunc after that, or will we need it to validate flags that may not be in the kubelet configuration object?

[mtaufen]

@dashpole yes, the feature-gates flag will go away in favor of componentconfig. The transform func will probably be around until we can stop enforcing flag precedence, which is likely a-long-time™.

[mtaufen]

/retest

[dchen1107]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dashpole, dchen1107, mtaufen

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• cmd/kubelet/OWNERS [dchen1107]
• pkg/kubelet/apis/kubeletconfig/OWNERS [dchen1107,mtaufen]
• pkg/kubelet/kubeletconfig/OWNERS [dchen1107,mtaufen]
• staging/src/k8s.io/apiserver/OWNERS [dchen1107]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-github-robot]

Automatic merge from submit-queue (batch tested with PRs 63881, 64046, 63409, 63402, 63221). If you want to cherry-pick this change to another branch, please follow the instructions here.