adopt kubeadm's v1beta4 API

[cjc7373]

Most noticeable change to me is v1beta4 uses list instead of map in extraArgs. The kubernetes' documentation now uses new format in all examples. (e.g. here)

ref: kubernetes/kubeadm#2890

[stmcginnis]

This is being worked on in #3675.

[BenTheElder]

Yeah, the problem is that this is a significantly breaking change, what we typically do is make kind aware of how to use it, then enable it starting with some kubernetes version that isn't released yet (like say v1.33.0) so that it can't break users unless they switch kubernetes versions (and therefore need to re-evaluate the patches anyhow)

However this one will need additional guidance, because a lot of users have been successfully writing version-independent patches, this will break a lot of trivial patches adding an argument, that will now need to be converted to multiple version-specific patches.

More discussion in #3675

/kind feature

[BenTheElder]

/triage accepted

[BenTheElder]

I think we'll need to target this at say, v1.33.0+ (which doesn't exist yet), so we can then go around and make sure there's been warning that you have to start handling this in your patching (and start setting your other patches to explicitly target v1alpha3)

Also, I think we'll have to fork #3675 as the author hasn't been available for a while now.

[BenTheElder]

And we'll need to find scripts like https://github.com/kubernetes/test-infra/pull/34257/files#r1943764665 in the project and start making them gracefully handle multiple config patch versions instead of using versionless patches (That work for v1beta1,2,3 but not 4 now)

[BenTheElder]

"support" doesn't quite capture it, we don't have a way to select arbitrary api versions as a user and that would be .... substantially more complex, we automatically use a current version based on the Kubernetes version which then requires users to use this version (which would eventually happen anyhow as kubeadm drops support for old config formats)

someday kubeadm will use a GA api type, and then this will be stable, but that's a fair bit of work and a major commitment from that project

(also even in that case kubelet and kube-proxy component config are also not GA)