Closed elohmeier closed 1 month ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
Is there something we need to do as the cloudprovider
to make this possible? Otherwise this looks like an area/core-autoscaler
issue.
@apricote Looking at the relevant provider code, it seems possible that on failure it logs a message, but neglects to return the error from IncreaseSize
. This means the core autoscaler does not have any indication the scaleup has failed. (More generally, this could affect any provider that neglects reporting an error from IncreaseSize
...)
Thanks for the hint @tallaxes! I opened a PR to properly return encountered errors.
Which component are you using?:
Cluster Autoscaler
What version of the component are you using?:
registry.k8s.io/autoscaling/cluster-autoscaler:v1.26.4
Component version:
What k8s version are you using (
kubectl version
)?:kubectl version
OutputWhat environment is this in?:
Hetzner Cloud
What did you expect to happen?:
When the cluster autoscaler is configured with a priority expander, and multiple node groups of differing priorities are provided, the cluster autoscaler should back-off after some time if the cloud provider fails to provision nodes in the high priority node group due to resource unavailability and proceed to lower priority node groups.
What happened instead?:
The high priority node group (in the below log pool1) has no resources available currently to provision the requested nodes. The cluster autoscaler is stuck in a loop trying to provision nodes in the high-prio group and not proceeding to pool2 (lower prio, resources available). I've also tried to set
--max-node-group-backoff-duration=1m
with no effect.How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?: