Change:
"v":                   true, "vmodule":             true, "log-flush-frequency": true, <ins> "provider-id":         true, </ins> } fs.VisitAll(func(f *pflag.Flag) { if notDeprecated[f.Name] {

Discussion:
Un-deperecate the kubelet flag, as this option is typically set per-node similar to (which is not deprecated). Or more generally, consider not deprecating fields available in config that make sense to set per-node. I noticed this while trying to ensure KIND moves towards not setting any deprecated flags, this one is tricky because it's not a fixed value. For a lot of kubernetes users, kubeadm is used for bootstrapping, and kubeadm supports supplying additional kubelet flags when configuring each node, but the kubelet config is cluster-wide, created during setting up the first node and uploaded to a configmap then used for all nodes. In the future kubeadm may have the ability to do per-node kubelet config, but that effort will probably be involved and isn't staffed at the moment. technically you could run kubeadm in phases and then modify the config, but this is more complex to implement. It's possible this won't be necessary if kubeadm patches can be extended to kubelet which may be a smaller feature change for kubeadm, but personally I think being able to configure simple per-node strings with a flag override is desirable for implementing clusters, and we've had the flag for many years with no trouble ... The actual deprecation seems to be due to a blanket deprecation on things possible to set in config, and not targeted at this flag in particular. See discussion in
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
technically KIND doesn't strictly need this flag, FWIW, but we were asked by users to set it to make detection easier and have values more similar to "real" clusters. other projects in Kubernetes are also doing this, e.g. some of of the cluster api-provider implementations:
I think for 1.25 in kubeadm we can enable patching of kubeletconfuguration.

This will allow us to use the current global kubletconfiguration for all nodes, but patches can act as the node instance specific config. Flags would still take precedence over patches and are the simpler UX. But if one day all flags are removed the above solution will still support the instance specific use case. I don't know whether some flags should be de-deprecated, but IIRC the plan to migrate all flags to kubeletconfiguration and not add more flags was still desirable by sig node.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
/assign It seems to be reasonable. I opened to undeprecate it.