Consider if to add Patches field to InitConfiguration and JoinConfiguration

[fabriziopandini]

Detailed Description

kubernetes/kubernetes#103063 recently added InitConfiguration.Patches.Directory, JoinConfiguration.Patches.Directory to allow the user to configure a directory from which to take patches for components deployed by kubeadm.

Should we add the same to the KubeadmConfig type in CAPI?

Anything else you would like to add:

IMPORTANT: This will work only on clusters with Kubernetes version >= 1.22

/kind feature
/area bootstrap

[sbueringer]

I think it would be really useful. We had to use the functionality to patch requests/limits/initContainer/... of the control plane static pod manifests because kubeadm didn't expose those fields.

[vincepri]

/milestone Next

[randomvariable]

I've seen requests to enable this. In particular in vSphere environments, some folks switch off their entire cluster, and when they turn it back on the entire cluster goes into CrashLoopBackoff as every etcd node complains about missing nodes on it's health status even though it's available. It's possible to work around it by changing the livenessProbe to check only that serializable (local) read, e.g.

ETCDCTL_API=3 etcdctl --endpoints=https://[127.0.0.1]:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --key=/etc/kubernetes/pki/etcd/healthcheck-client.key get --consistency="s" foo

I will also check in kubeadm to see if we should change the livenessProbe entirely as it seems wrong to have the entire cluster go into crashLoopBackoff and never recover.

[vincepri]

We should definitely file a bug in upstream kubeadm as well

[neolit123]

looks like @randomvariable filed the kubeadm ticket. it also links to a new etcd repo ticket, where the main question is how to enable more granular checks or relax the existing checks.
kubernetes/kubeadm#2567
feels like adjusting this in kubeadm should be done.

kubeadm patches in CAPI make sense in general and @randomvariable and me discussed this today at the VMware slack.

[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

[fabriziopandini]

/remove-lifecycle stale
given that there is a PR out for it