Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(helm): update HPA to autoscaling/v2 #465

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

davidspek
Copy link
Contributor

Related to: #449

This PR updates the HPA API version in the helm chart from autoscaling/v2beta1 to autoscaling/v2. This means that people using the HPA will need to be using Kubernetes at least v1.23.0. Since Kubernetes v1.27.0 was recently released I believe this shouldn't be a large problem.

Signed-off-by: David van der Spek <vanderspek.david@gmail.com>
@yetone
Copy link
Member

yetone commented May 5, 2023

Thank you for your contribution! Does this mean that a k8s cluster with v1.22 will no longer be able to upgrade Yatai?

@davidspek
Copy link
Contributor Author

@yetone It would mean there is a minimum version for Kubernetes for the Helm chart. However, if you like I can do a check for the supported API versions and have it use the newest available one to allow for support with older Kubernetes versions.

@yetone
Copy link
Member

yetone commented May 11, 2023

@davidspek Thank you for your reply. As the Yatai installation document promises support for k8s 1.20+, it is likely that many users with k8s 1.20-1.22 have already installed Yatai. Therefore, we should also ensure compatibility with k8s 1.20-1.22; otherwise, these users will not be able to continue updating Yatai.

@davidspek
Copy link
Contributor Author

I can make that work. I initially didn't do this since if my other PRs to update the controller code to use autoscaling/v2 would be merged then those would cause the version requirement to change as well, in which case backwards compatibility for the helm chart doesn't make much sense. But if a more sophisticated solution is implemented for maintaining backwards compatibility in the controller and backend code then it does make sense to also do this for the helm chart.

@ajadams-ml
Copy link

I'm currently upgrading our k8s clusters to 1.25 and autoscaling/v2beta1 is blocking me from proceeding. Is this going to get merged in the near future?

@knechtionscoding
Copy link

I think that using capabilities and allowing for an override of the k8s version, with a fall back to v1beta1 would work.

Allow someone to specify the hpa version in values.yaml else use capabilities to determine the correct version to use, finally fall back to the acceptable one of v1beta1 that maintains backwards compatibility and allows for a wider version of support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants