Make use of Capabilities.KubeVersion so we do not need to override image.tag in Helm Values

[miroljub1995]

Which component are you using?:
cluster-autoscaler (helm)

Is your feature request designed to solve a problem? If so describe the problem this feature should solve.:
no

Describe the solution you'd like.:
It would be great if image tag could be inferred based on Capabilities.KubeVersion so that we do not need to override image.tag in Chart Values. Right now default tag is v1.23.0, but if we run on k8s v1.24, we need to override it to v1.24.0.

Describe any alternative solutions you've considered.:
The only alternative way is to set image.tag explicitly.

[khizunov]

@miroljub1995 Looks like cool feature, but the KubeVersion will not necessary match the autoscaler image tag.

[Shubham82]

@gjtempleton your thoughts on this?

[Shubham82]

if this seems valid, then I will give it a try.
/assign

[gjtempleton]

Hey, thanks for the suggestion, as @khizunov says, the KubeVersion won't necessarily match the image tag, particularly the patch version, as well as the lag between a new minor release of k8s being cut and the relevant CA image being released/promoted.

If we were to support this, I certainly wouldn't want it being the default behaviour unless we had a reliable way of fetching the latest patch release for the detected minor version and using that as an input.

[Shubham82]

Hi @gjtempleton

If we were to support this, I certainly wouldn't want it being the default behaviour unless we had a reliable way of fetching the latest patch release for the detected minor version and using that as an input.

Could you please give any pointer or lead on how we can proceed with this?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Shubham82]

/remove-lifecycle stale

[Shubham82]

Hi @gjtempleton
I saw your comment on the issue: #5640. I agree with your point.

Is there any way or pointer to start with this?

Also, we need the same minor version of k8s for CA, but there is always a delay in the release of the CA corresponding to the k8s release and it affects the chart version. we have to consider this thing also. suppose a user uses the new release of k8s but we would not have the corresponding release of CA at that time so what version it would consider for CA?

[Shubham82]

Hi @gjtempleton I saw your comment on the issue: #5640. I agree with your point.

Is there any way or pointer to start with this?

Also, we need the same minor version of k8s for CA, but there is always a delay in the release of the CA corresponding to the k8s release and it affects the chart version. we have to consider this thing also. suppose a user uses the new release of k8s but we would not have the corresponding release of CA at that time so what version it would consider for CA?

@gjtempleton, your thoughts on the above comment?

[Shubham82]

Hi @gjtempleton PTAL!

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Shubham82]

/remove-lifecycle stale

[Shubham82]

Hi @gjtempleton I saw your comment on the issue: #5640. I agree with your point.

Is there any way or pointer to start with this?

Also, we need the same minor version of k8s for CA, but there is always a delay in the release of the CA corresponding to the k8s release and it affects the chart version. we have to consider this thing also. suppose a user uses the new release of k8s but we would not have the corresponding release of CA at that time so what version it would consider for CA?

@gjtempleton, could you please take a look at this?

Thanks!

[Shubham82]

IMO, making image.tag version as same as the Kubernetes Version is not feasible because the minor or patch version for the CA chart is not always the same as the Kube version. Minor/Patch version (as per changes) for the charts is released after every change in the charts.
What if we can set image.tag explicitly as a workaround for this?
any thoughts on this?

[Shubham82]

IMO, making image.tag version as same as the Kubernetes Version is not feasible because the minor or patch version for the CA chart is not always the same as the Kube version. Minor/Patch version (as per changes) for the charts is released after every change in the charts. What if we can set image.tag explicitly as a workaround for this? any thoughts on this?

cc @gjtempleton, PTAL!

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Shubham82]

/remove-lifecycle stale

[Shubham82]

IMO, making image.tag version as same as the Kubernetes Version is not feasible because the minor or patch version for the CA chart is not always the same as the Kube version. Minor/Patch version (as per changes) for the charts is released after every change in the charts. What if we can set image.tag explicitly as a workaround for this? any thoughts on this?

cc @gjtempleton, could you please take a look?

/lifecycle frozen