Allow running kubeadm upgrade apply in the non-interactive mode when the --config flag is used

[xmudrii]

What keywords did you search in kubeadm issues before filing this one?

non-interactive, --yes

Is this a BUG REPORT or FEATURE REQUEST?

kubeadm 1.30: Bug report
kubeadm 1.31+: Feature request

Versions

kubeadm version (use kubeadm version): 1.30+

kubeadm version: &version.Info{Major:"1", Minor:"30", GitVersion:"v1.30.1", GitCommit:"6911225c3f747e1cd9d109c305436d08b668f086", GitTreeState:"clean", BuildDate:"2024-05-14T10:49:05Z", GoVersion:"go1.22.2", Compiler:"gc", Platform:"linux/amd64"}

Environment:

• Kubernetes version (use kubectl version): 1.30+
• Cloud provider or hardware configuration: Not relevant
• OS (e.g. from /etc/os-release): Not relevant
• Kernel (e.g. uname -a): Not relevant
• Container runtime (CRI) (e.g. containerd, cri-o): Not relevant
• Container networking plugin (CNI) (e.g. Calico, Cilium): Not relevant

What happened?

kubeadm allowed running kubeadm upgrade apply with the --config flag provided in the non-interactive mode by using the --yes flag. The --yes flag had only one task and that's to skip interactive confirmations where you have to type yes/y to proceed. This feature has been very useful and allowed running kubeadm in fully-automated scripts where typing anything, or in this case yes, is not an option.

This however stopped working with kubeadm 1.30. Trying to run kubeadm upgrade apply <version> --config <path> --yes with kubeadm 1.30 results in the following error:

can not mix '--config' with arguments [yes]
To see the stack trace of this error execute with --v=5 or higher

As a side note, in kubeadm 1.30 and the v1beta3 API, there's no option to enable the non-interactive mode via the config file, so using the --yes flag is the only option to enable the non-interactive mode. Additionally, I'm aware that using the --config flag in this concrete case is discouraged/deprecated.

kubeadm 1.31 introduces the v1beta4 API which has the ForceUpgrade field that enables the non-interactive mode, however, as a side effect and with some serious implications. The ForceUpgrade option (aka the --force-upgrade flag), allows unsafe upgrade combinations, e.g. if some checks failed, if version skew policy is not satisfied, etc. This can be seen in https://github.com/kubernetes/kubernetes/blob/5df8e15a84bb3d6c80c57f0d4b50fa0c1864ca8e/cmd/kubeadm/app/cmd/upgrade/apply.go#L235-L257 and https://github.com/kubernetes/kubernetes/blob/5df8e15a84bb3d6c80c57f0d4b50fa0c1864ca8e/cmd/kubeadm/app/phases/upgrade/policy.go#L47-L150. This is much different compared to the --yes flag which only skipped the interactive confirmations.

That said, even with kubeadm v1.31+ and the v1beta4 API, there's still need for the --yes flag to make using kubeadm in the fully-automated scripts easier/possible and safe.

What you expected to happen?

The --yes flag should keep the behavior prior to 1.30, where you could use both --config and --yes flags together in the kubeadm upgrade apply command.

From the user perspective, keeping the flag instead of putting it in the API makes a couple of things easier. If I want to run kubeadm as part of some fully-automated script, I can just use the --yes flag. If I want to test something interactively and see if checks are going to pass, I can omit the flag and then answer yes/no depending on if I'm satisfied by proposed changes.

How to reproduce it (as minimally and precisely as possible)?

Run kubeadm upgrade apply <version> --config <path> --yes with kubeadm 1.30.0 or newer.

Anything else we need to know?

Additional discussion on Slack about this: https://kubernetes.slack.com/archives/C13J86Z63/p1718644261743749

[neolit123]

can not mix '--config' with arguments [yes]

as i said on slack maybe we should just allow --yes to be mixed with config and don't add a "yes" field in v1beta4 config.

[faszhang]

@neolit123 when the change will be cherry-picked to 1.30