Use latest kubeVersion as helm parameter when rendering charts in mirror-images

[SimonTheLeg]

What this PR does / why we need it:

This PR fixes the issue where the mirror-images command is going to fail when using it with charts that specify a Kubernetes version greater than 1.20. This is currently the case for the consul chart.

Tested with the current installer from the latest KKP Github release:

./kubermatic-installer mirror-images registry.example.com --config examples/kubermatic.example.yaml --dry-run
INFO[0003] 🚀 Collecting images…
INFO[0147] 🚀 Rendering Helm charts…                      charts-directory=charts
ERRO[0168] ❌ Operation failed: failed to get images: failed to get images for Helm chart: failed to render Helm chart "consul": Error: chart requires kubeVersion: >=1.21.0-0 which is incompatible with Kubernetes v1.20.0

---

The reason for this is a little bit entertaining. Helm actually uses a kubeVersion flag to specify how a chart should be rendered. This is by default hardcoded to 1.20 (see https://github.com/helm/helm/blob/main/pkg/chartutil/capabilities.go#L32-L48 & https://github.com/helm/helm/blob/main/pkg/chartutil/capabilities_test.go#L45) and therefore can collide with charts that specify a kubeVersion greater than 1.20.

What type of PR is this?

/kind bug

Special notes for your reviewer:

Two changes in this PR should be reviewed closer:

1. This introduces the ability to pass flags into the RenderChart func. This is done in accordance with other funcs in the interface which allow similar features (e.g InstallChart)
2. The mirror-images command now uses the latest Kubernetes version we support in KKP as the basis for the render. I have written a longer comment in the the func to explain this. PTAL if that behaviour makes sense to you.

Does this PR introduce a user-facing change? Then add your Release Note here:

Fix an issue in the kubermatic-installer mirror-images command, which led to failure on the mla-consul chart

Documentation:

NONE

[xrstf]

/approve
/lgtm

[kubermatic-bot]

LGTM label has been added.

Git tree hash: 7b444dc42cd888992b1c9a1f927829a61ee39c86

[kubermatic-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: SimonTheLeg, xrstf

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• cmd/kubermatic-installer/OWNERS [xrstf]
• pkg/install/OWNERS [xrstf]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[wurbanski]

@SimonTheLeg would it make sense to use the oldest supported version instead?

[SimonTheLeg]

@wurbanski I have been contemplating this topic and came to the conclusion that using the oldest supported version is more brittle than using the latest one. My logic behind this is based on that I think it is more likely that the author of a chart will have a version constraint eliminating old versions, than they will have a constraint limiting new versions.

[wurbanski]

I forgot we're not using it for anything other than listing images at the moment, nevermind. :)

[xrstf]

Should we backport this?

[SimonTheLeg]

yes I think this makes sense. Otherwise the KKP 1.23 installer will not be usable

/cherrypick release/v2.23

[kubermatic-bot]

@SimonTheLeg: new pull request created: #12517

In response to this:

yes I think this makes sense. Otherwise the KKP 1.23 installer will not be usable

/cherrypick release/v2.23

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.