cc @SergeyKanzhelev @ehashman

#61673 as well.

If this could be considered an instance-specific flag, or a descriptor of local topology
managed by the Kubelet, see: #61647.

If this flag is only registered in os-specific builds, see: #61649.

Link to the enhancement issue as well kubernetes/enhancements#281.

the feature was enabled in kubeadm as optional, but we removed it recently.

prior feedback from users was that they could not get it work with the kubeadm wrapped option or by following the official docs:
https://kubernetes.io/blog/2018/07/11/dynamic-kubelet-configuration/

dynamic reconfiguration of services is a interesting discussion, yet from what i've seen SIG Arch are mostly not in favor.
but arguably dynamic reload of certs from disk falls in the same bucket and we are already doing that for some component flags.

but arguably dynamic reload of certs from disk falls in the same bucket and we are already doing that for some component flags.

I don't think that's in the same bucket... dynamic refresh of a time-bound portion of a configuration (like a CA bundle or an authentication token) seems very different from changing the configuration.

i still consider it dynamic reconfiguration of a service, that may or may not have behavior changes.
changing the CA bundle that a server accepts can have behavior changes for clients trusting the same server.

we discussed this in sig-node and @SergeyKanzhelev said he would explore this in more depth during 1.22.

I agree with @liggitt that auto reload of the CA bundle is not in the same category of DynamicKubeletConfig.

It's the difference between changing the filepath (dynamic config) and just reloading the file at a fixed location (CA reload).

Sure it's technically a change but if config is specifying intent, and the intent is "reload this file periodically," then changing the target file is not changing intent.

/assign @SergeyKanzhelev
/triage accepted
/kind deprecation

Hey all, question on the roll-out of this. Discussion seems to say that the you're going to look into this and this is behind a beta featuregate - not familiar with this feature - but which part of the deprecation policy would this fall into: https://kubernetes.io/docs/reference/using-api/deprecation-policy

What release would this be targeted to be finally deprecated with feature gate removed?

I think the relevant portions of the deprecation policy would be:

Rule #5b: CLI elements of admin-facing components (e.g. kubelet) must function after their announced deprecation for no less than:

...

• Beta: 3 months or 1 release (whichever is longer)

Rule #8: Feature gates must be deprecated when the corresponding feature they control transitions a lifecycle stage as follows. Feature gates must function for no less than:

...

• Beta feature to EOL: 3 months or 1 release (whichever is longer)

Let's track this work as a KEP so there are less bugs in k/k repository. Also helps with linking to the KEP - instead of linking PRs to this issue.

/close

@SergeyKanzhelev: Closing this issue.

Note: the KEP is kubernetes/enhancements#281 (comment)