undeprecate kubelet --provider-id flag

[BenTheElder]

What would you like to be added?

Un-deperecate the --provider-id kubelet flag, as this option is typically set per-node similar to --node-ip (which is not deprecated).

Or more generally, consider not deprecating fields available in config that make sense to set per-node.

Why is this needed?

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.
kubernetes-sigs/kind#2764

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 ...

kubernetes/kubeadm#1682 (comment)

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 https://kubernetes.slack.com/archives/C0BP8PW9G/p1652465646070179

[k8s-ci-robot]

@BenTheElder: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[BenTheElder]

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:
https://github.com/kubernetes-sigs/cluster-api-provider-digitalocean/blob/32ed18d5e68fc61f8ba7150d6ddaddf7e47f967a/test/e2e/data/infrastructure-digitalocean/cluster-template-prow-ci-version.yaml#L113

https://github.com/kubernetes-sigs/cluster-api-provider-ibmcloud/blob/4433897dff2932fa37585159d05cb03d53be273f/config/manager/manager.yaml#L31

[neolit123]

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.

[k8s-triage-robot]

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, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[BenTheElder]

/remove-lifecycle stale

[k8s-triage-robot]

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, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

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, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[BenTheElder]

/remove-lifecycle rotten

[pacoxu]

/assign
It seems to be reasonable. I opened #116530 to undeprecate it.