Ignition v3.x support

[bengentil]

What would you like to be added (User Story)?

As a user I would like to bootstrap Flatcar & FCOS with Ignition v3.x as Ignition v2.x doesn't work with FCOS and is only required for flatcar LTS release.

Detailed Description

The current implementation (Container Linux Config aka clc) is used when setting format to "ignition" in KubeadmConfigSpec.
To be able to support both v2.x & v3.x, a new field needs to be added to know which transpiler should be used:

• clc for v2.x
• butane for v3.x

Like in the current implementation, an additional butane config may be provided to extend/override the generated Ignition config.

Anything else you would like to add?

This issue follows this slack conversation: https://kubernetes.slack.com/archives/C8TSNPY4T/p1688643597808979

Label(s) to be applied

/kind feature
/area bootstrap
/area provider/bootstrap-kubeadm

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors 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.

[vincepri]

/priority important-soon

[JoelSpeed]

I've been looking into this a little and concluded that resolving this should be relatively straight forward, at least, on the providers side.

Looking at AWS as an example. The only thing it does for ignition is to upload the existing ignition data to s3 and then create a stub ignition which points to the s3 bucket.

There are minor differences between v2 and v3, but, it's not hard to create a switch and support this by importing both the v2 and v3 types.

For kubeadm this may be a little bit more involved.

Does anyone know about the flatcar ignition fork vs the coreos ignition? I was looking at both today and as far as I can tell they are API compatible, but the coreos fork seems to be more active at the moment?