Support for k8s version 1.33.x

[tzabbi]

Does somebody know when the support for version 1.33.x will be released?

Thanks Tom

[adrianmoisey]

For which application? Is this cluster-autoscaler?

[tzabbi]

Oh yeah sorry. I mean the cluster autoscaler.

[adrianmoisey]

/area cluster-autoscaler /kind support

[mohag]

It seems like a release was scheduled. The maintainer made a commit before that day as well.... I'm not sure if something got forgotten somehow...

[tzabbi]

@mohag thanks for this information. It confuses me why there is no release when both are merged...

[bs258q]

@mohag @tzabbi even am just waiting for compatible cluster-autoscaler version for eks 1.33, any ETA on why they will publish the release

[mrburrito]

Is 1.32.0 compatible with 1.33.0 or will I see issues if there's a mismatch?

[mohag]

Is 1.32.0 compatible with 1.33.0 or will I see issues if there's a mismatch?

It runs and autoscales - it is possible that there might be some edge cases (AFIAK, the reason that the versions should match is that it contains a copy of the scheduler for the k8s version to simulate changes - mismatches can result in the simulation and reality not matching...)

[ankursgupta87]

@jackfrancis @x13n Any idea by when we can expect cluster-autoscaler 1.33 release ?

[r8or0pz]

Yeah, waiting for 1.33...

[x13n]

I believe @jackfrancis already built the images, they just need to be promoted to the public image registry.

[ankursgupta87]

@x13n Can you please help with promoting images for 1.33 to public registry ?

[fgarcia-0]

1.33.0 is available from registry, i was able to pull it this morning (but not referenced in README) after 1.32.1 scaled down an 'empty node' with 18 pods on. hope not to face that again ^^

[itsjgf]

I see that cluster-autoscaler-1.33.0 was released a few hours ago.

Are there any updates or an estimated timeline for when the Helm chart will be updated to support this version?

[mohag]

There is no release listed on this repo though (I detect the relevant version by fetching all the releases from the github API and looking for the latest cluster-autoscaler that matches the Kubernetes version) (I mostly just use the latest version of the chart and set the tag)

[boatmisser]

https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.33.0

But the latest helm chart is still 1.32.0

[mohag]

https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.33.0

But the latest helm chart is still 1.32.0

You can set the tag with this in you values file: (or --set image.tag=v1.33.0)

image:
  tag: v1.33.0

You likely should be doing that anyway, since the container version should match your cluster's minor version and setting the tag is easier than figuring out which helm chart version references which image version...

[tzabbi]

https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.33.0

But the latest helm chart is still 1.32.0

You can set the tag with this in you values file: (or --set image.tag=v1.33.0)

image:
  tag: v1.33.0

You likely should be doing that anyway, since the container version should match your cluster's minor version and setting the tag is easier than figuring out which helm chart version references which image version...

I don't agree with that. To my mind you should update the helm Chart Version to update the application. Do you have some guides or best practices where it is recommended to set the image tag manually?

[joaope]

https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.33.0 But the latest helm chart is still 1.32.0

You can set the tag with this in you values file: (or --set image.tag=v1.33.0)

image: tag: v1.33.0 You likely should be doing that anyway, since the container version should match your cluster's minor version and setting the tag is easier than figuring out which helm chart version references which image version...

Not sure folks should be doing that, really. Chart's appVersion is literally hardcoded to 1.32.0. Not the first time I've had this internal mental debate with myself about why charts, specially the ones with applications behind them like autoscaler, even expose image.tag at all.

I'm sure there's a valid reason to change image.tag manually (e.g.: custom image) but this is not one of them.

[jackfrancis]

I agree with folks who suggest we should update the helm chart to reference 1.33.0. I'll do that today!

[mohag]

https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.33.0 But the latest helm chart is still 1.32.0

You can set the tag with this in you values file: (or --set image.tag=v1.33.0) image: tag: v1.33.0

You likely should be doing that anyway, since the container version should match your cluster's minor version and setting the tag is easier than figuring out which helm chart version references which image version...

I don't agree with that. To my mind you should update the helm Chart Version to update the application. Do you have some guides or best practices where it is recommended to set the image tag manually?

There is no way to get versions like 1.31.2 without setting the tag - there are no releases of the chart for patches within a minor version. (I do see that there are version specific chart versioning. (Major changes to the chart is rare though, so it mostly works to ignore the appversion completely, instead of figuring out that you need to install chart 9.46.6 and set the tag to v1.32.1 to get the correct version for a 1.32 cluster)

The fix for that is to always release a new chart with patches, then the chart details can be used to detect it (I have an Ansible setup dealing with the versions and the Github API is easy, figuring out available chart versions and their app versions automatically are not) (Running a Helm search command with JSON / YAML output and then processing the data is the way to do that)

[luizm]

I agree with folks who suggest we should update the helm chart to reference 1.33.0. I'll do that today!

I've done it https://github.com/kubernetes/autoscaler/pull/8295

[tzabbi]

There is no way to get versions like 1.31.2 without setting the tag - there are no releases of the chart for patches within a minor version. (I do see that there are version specific chart versioning. (Major changes to the chart is rare though, so it mostly works to ignore the appversion completely, instead of figuring out that you need to install chart 9.46.6 and set the tag to v1.32.1 to get the correct version for a 1.32 cluster)

Yeah, but then this is a design decision by the maintainer team. Eighter, you want to release an update when an application update is available or not.

@jackfrancis can we automate this kind of helm release mechanism, or you have different opinion?

[greenozon]

@tzabbi should this issue be closed? 1.33 was already released...

[tzabbi]

@greenozon Basically yes. The reason why this issue is still open is my question if we want to make an autorelease everytime when the application got a new release.

[greenozon]

good point do you know who is decision maker on this q?

[tzabbi]

I think it's @jackfrancis

[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