v1alpha5 API design

[BenTheElder]

We should add a new API revision in order to make some improvements, here is what I have in mind:

1. dual-stack network configuration (a good reason for people to upgrade 🙃 ) Add dual stack support #692 DualStack UX #1275
2. extraMounts should only resolve paths to absolute if they contain a path separator support docker volumes in extra mounts #1966
   • I.E. bare filenames / directories will need to go from foo to ./foo, unless they are already foo/bar, in which case they will still be resolved
   • Doing this will allow us to support support docker volumes in extra mounts #1966
   • support docker volumes in extra mounts #1966 will allow us to support a form of Customise Docker volume #1834
3. kubeadmConfigPatches => componentConfigPatches + enhance Kubernetes component config patching
   • Doing this allows us to support future component config patching without more fields
   • This is more consistent with the intention of the existing field now that we're not using only kubeadm component config
   • We should rewrite the bootstrapping process to use modern kubeadm (phases) and patch per-node kubelet config on-disk
   • We should reject per-node kube-proxy config (only allow this on the cluster-wide config patches)
   • We should reject per-node kubeadm init config if it's not on the correct node (first control-plane), or just on all nodes
   • We should consider rejecting kubeadm join config if it's on the first control-plane node
4. Support node labeling in config Support node labels within config files #1574 / added: support for adding labels from the config file itself #1926

I'm aware of other possible improvements not named above, but I think this is already a lot to work on for the next release, besides changes that aren't API specific, listing them anyhow to start thinking about some more:

• GPUS: add gpus support in docker provider #1886
• Docker registry: Better UX for using local registry #1213 (it's a bit unclear what the lifecycle should look like / if this should be in cluster config), I'd sort of like to do this one, but I don't want to agree to it as I think we're more directly blocked on some of these other changes, while clunky the existing registry options do work.

[BenTheElder]

We should also start labeling when support for a field was introduced in https://kind.sigs.k8s.io/docs/user/configuration/ and ensure all fields are in that doc.

EDIT: this is now #2026

[neolit123]

kubeadmConfigPatches => componentConfigPatches + enhance Kubernetes component config patching

i like this.

[aojea]

For dualstack we don't need anything new, just a new field for networking.IPFamily

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[aojea]

/remove-lifecycle stale

[BenTheElder]

1 & 4 shipped as additions to v1alpha4

2 pretty much has to be a new one I think, because it's a breaking behavior change in the field.

3 is pretty high effort and I'm not sure we're finding the time. I think it should still happen, but I'm not sure when ...