kubeadm: Remove the support of configurable component configs

[chendave]

kubeadm upgrade plan uses to support the configure of component configs(kubeproxy and kubelet) in a config file and then check if the version is supported or not, if it's not supported it will be marked as a unsupported version and require to manually upgrade the component.

This feature will make the upgrade config API much harder as this violates the non-mutation principle for upgrade, and we have seen it's quite problematic to do like this.

This change removes the support of configurable component configs for kubeadm upgrade plan, along with the removal, the logic to parse the config file to decide whether a manual upgrade for the component configs is needed is removed as well.

NOTE that API is not changed, i.e. ManualUpgradeRequired is not removed from ComponentConfigVersionState but it's no-op now.

split from: #114062

more context:
#114062 (comment)
#114062 (comment)

This is one step forward upgrade config API.

What type of PR is this?

/kind feature

What this PR does / why we need it:

Which issue(s) this PR fixes:

Related: #114062

Special notes for your reviewer:

Does this PR introduce a user-facing change?

ACTION REQUIRED: stop accepting component configuration for kube-proxy and kubelet during `kubeadm upgrade plan --config`. This is a legacy behavior that is not well supported for upgrades and can be used only at the plan stage to determine if the configuration for these components stored in the cluster needs manual version  migration. In the future, kubeadm will attempt alternative component config migration approaches.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

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.

[chendave]

this change is marked as ACTION REQUIRED, even though I am not sure what action a end-user should take.

If end-user provide a config file with component configs, then it will be just ignored.

How about print some warning here, saying, this is no longer supported and remove the ACTION REQUIRED from release note?

[neolit123]

we should add action required on breaking changes or changes in user expectations.

in this case if they were using the --config the component config would have been updated in the cluster, right? we seem to be changing this behavior, so they must do it manullay now before upgrade.

ideally this should have been a v1beta4 change only. but it's likely complicated to do.

i think we should start erroring on Kind that is not upgradeconfiguration passed on upgrade.

[chendave]

the component config would have been updated in the cluster

IIUC, the only thing I can see is if the version is different from current value (defined kubelet = v1beta1, kubeproxy = v1alpha1), then asking for manually upgrade, other than that, I didn't see anything different.

it's in the phase of plan so no real action would be taken.

[chendave]

i think we should start erroring on Kind that is not upgradeconfiguration passed on upgrade.

+1, let me consolidate this logic into #114062

[neolit123]

the component config would have been updated in the cluster

IIUC, the only thing I can see is if the version is different from current value (defined kubelet = v1beta1, kubeproxy = v1alpha1), then asking for manually upgrade, other than that, I didn't see anything different.

it's in the phase of plan so no real action would be taken.

that may be true. i have forgotten what logic was added.

[neolit123]

ACTION REQUIRED: kubeadm will not support the configure of component configs for kubeadm upgrade plan, it will be just ignored if configured.

suggesting:

kubeadm: stop analyzing component config on "kubeadm upgrade". do not show warnings for outdated kube-proxy or kubelet configuration.

like you said, there is no action for the user to take here.
but if we stop accepting only upgrade config, that's an action required. so we have to explain it on a different pr.

maybe after the upgrade config pr merges, because that pr is already huge?

[neolit123]

/approve
/hold

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: chendave, neolit123

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/kubeadm/OWNERS [neolit123]

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

[pacoxu]

Probably, we should check https://github.com/kubernetes/enhancements/blob/0a6d6c888298c4381d3bedd2134a2e8ec098cab3/keps/sig-cluster-lifecycle/kubeadm/1381-component-config/README.md#kubeadm-upgrade-plan-changes that if the KEP needs some update.

[neolit123]

Probably, we should check https://github.com/kubernetes/enhancements/blob/0a6d6c888298c4381d3bedd2134a2e8ec098cab3/keps/sig-cluster-lifecycle/kubeadm/1381-component-config/README.md#kubeadm-upgrade-plan-changes that if the KEP needs some update.

+1 @chendave PTAL and send PR with update there if needed.

[neolit123]

/release-note-edit

ACTION REQUIRED: stop accepting component configuration for kube-proxy and kubelet during `kubeadm upgrade plan --config`. This is a legacy behavior that is not well supported for upgrades and can be used only at the plan stage to determine if the configuration for these components stored in the cluster needs manual version  migration. In the future, kubeadm will attempt alternative component config migration approaches. 

[neolit123]

^ @chendave please check if the updated release note makes sense for this PR.

still needs LGTM from another reviewer.

[neolit123]

Probably, we should check https://github.com/kubernetes/enhancements/blob/0a6d6c888298c4381d3bedd2134a2e8ec098cab3/keps/sig-cluster-lifecycle/kubeadm/1381-component-config/README.md#kubeadm-upgrade-plan-changes that if the KEP needs some update.

+1 @chendave PTAL and send PR with update there if needed.

KEP changes are OK, but they are not urgent.
can be done retroactively.

[neolit123]

^ @chendave please check if the updated release note makes sense for this PR.

still needs LGTM from another reviewer.

/cc @SataQiu
perhaps you remember when this CC logic was added for upgrades.

[chendave]

/release-note-edit

ACTION REQUIRED: stop accepting component configuration for kube-proxy and kubelet during `kubeadm upgrade plan --config`. This is a legacy behavior that is not well supported for upgrades and can be used only at the plan stage to determine if the configuration for these components stored in the cluster needs manual version  migration. In the future, kubeadm will attempt alternative component config migration approaches. 

thanks @neolit123 for the update! this is not urgent, let's wait for a double check from @SataQiu or @pacoxu

[chendave]

/kind feature

[chendave]

/kind feature

tag it as feature might not appropriate, but I am not sure is there any better choice. :)

[neolit123]

/kind feature

tag it as feature might not appropriate, but I am not is there any better choice. :)

/remove-kind feature
/kind deprecation

[pacoxu]

The behavior is to ignore or skip component configs(kubeproxy and kubelet) in --config.

The original is like below

The table below shows the current state of component configs as understood by this version of kubeadm.
Configs that have a "yes" mark in the "MANUAL UPGRADE REQUIRED" column require manual config upgrade or
resetting to kubeadm defaults before a successful upgrade can be performed. The version to manually
upgrade to is denoted in the "PREFERRED VERSION" column.

API GROUP                 CURRENT VERSION   PREFERRED VERSION   MANUAL UPGRADE REQUIRED
kubeproxy.config.k8s.io   v1alpha1          v1alpha1            no
kubelet.config.k8s.io     v1alpha2          v1beta1             yes

As #114062 (comment) discussed

this is not a common thing during upgrades. If we do not allow InitConfigiration on upgrade --config anymore, we are effectively breaking users that pass the component config +init configuration on upgrade.

/lgtm
Users may do the validation with kubeadm config validate --config before applying it to the configmap.

maybe after the upgrade config pr merges, because that pr is already huge?

@neolit123 Do you mean that this PR will be merged after #114062?

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 6787e93a52cd9fac26cf53145afdf85c75d51b76

[neolit123]

Users may do the validation with kubeadm config validate --config before applying it to the configmap.

+1

@neolit123 Do you mean that this PR will be merged after #114062?

this can merge before the upgrade config PR, as well. @chendave do as you prefer.

[chendave]

thanks @neolit123 and @pacoxu !

let's hold for more days in case @SataQiu want to comment.

I will push a change to update KEP as a follow up.

[SataQiu]

perhaps you remember when this CC logic was added for upgrades.

It was introduced by #88124.
Previously, this was used to give the user more information to help complete the upgrade smoothly.
Since it violates the non-mutation principle for upgrade, I'm ok with this change.

/lgtm

[chendave]

/unhold

thanks all for the review