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
Custom Scheduler Incompatible with Kubernetes 1.27 #3128
Comments
Is this bug still present in the latest dev release of this chart? |
Yeah this is fixed in latest dev release of the chart, there are breaking changes to see in #3113 |
Yep, fixed! Closing the ticket. Hopefully this ticket helps folks when searching the issue. My invocation:
and I was off to the races. |
@consideRatio Any insight when this change will be implemented in a non-dev release of the chart? |
3.0.0-beta.1 is out, changelog written for it! |
Bug description
AWS EKS recently released Kubernetes 1.27 for general availability. I upgraded and today jupyterhub users were saying their singleuser notebook servers couldn't boot. The pods appeared in the correct namespace but never left Pending, no Events attached to debug or anything.
Expected behaviour
Notebook servers boot on 1.27.
Actual behaviour
Turns out the pods used a custom scheduler and that scheduler had a unrecoverable error:
which makes sense, on Kubernetes 1.27 those APIs have been upgraded:
after manually patching the scheduler deployment to use 1.27.1:
and that had another error about lease type, fixed by setting the scheduler configmap to change
endpoints
toleases
:How to reproduce
Use Kubernetes 1.27
Run the latest stable helm chart with:
helm upgrade --install
jupyter-hub jupyterhub/jupyterhub
--namespace datascience
--version 2.0.0
--values config.yaml
Your personal set up
EKS 1.27
The text was updated successfully, but these errors were encountered: