Clarify how to use autopilot upgrades with dynamic configuration with overridden images via the clusterconfig

[emosbaugh]

Is your feature request related to a problem? Please describe.

When an installation has images overridden in the cluster spec, the documentation does not make it clear to me how to update these images in the dynamic configuration combined with an autopilot cluster upgrade.

Is there some order of operations that should be followed? If I upgrade the clusterconfig first the prior version may be running with the new images. If i upgrade after, the reverse. Additionally, it seems as if the new pause image will not be used.

Describe the solution you would like

Documentation providing steps to upgrade a cluster with overridden images.

Describe alternatives you've considered

Alternatively, a way to override the registry without overriding the image repos.

Additional context

No response

[jnummelin]

I don't think autopilot today has any support for this kinda use case unfortunately. 😢

What I think could work if we'd allow some sort of config "transformations" to be specified with the Plan. Some options/ideas for transformations:
yaml
User could add config patch, present autopilot would merge the given config yaml into the existing config before restarting k0s. Some validation would be nice to be done, but that might be difficult. The old/current version might not be actually able to validate the new config properly if new version bring new config options/keys.

jsonpath patches
ClusterAPI uses these in the ClusterClass transformations. Although a nice concept, PITA to write and maintain in real life. 👎