Closed georgebuckerfield closed 2 years ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs 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
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs 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 rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close
@k8s-triage-robot: Closing this issue.
Having this exact same issue! Very frustrating, because as far as I can tell the nodes get labeled right away, but the cluster-autoscaler still complains about it
/reopen
@bhperry: You can't reopen an issue/PR unless you authored it or you are a collaborator.
Which component are you using?:
cluster-autoscaler (with the priority expander)
What version of the component are you using?:
Component version: 1.21.0 (but I'm seeing the same behaviour with 1.23.0)
What k8s version are you using (
kubectl version
)?:kubectl version
OutputWhat environment is this in?:
AWS EKS
What did you expect to happen?:
When an unschedulable pod with a persistent volume triggers a scale-up, there should only be one scale-up for that pod.
What happened instead?:
There are two scale-ups for the pod.
How to reproduce it (as minimally and precisely as possible):
The behaviour we're seeing is this:
web-1
in these logs), which uses a persistent volume in eu-west-1atest-ebs-scaling-test-t-medium-spot-eu-west-1a
)k8s.io/cluster-autoscaler/node-template/label/topology.ebs.csi.aws.com/zone
tag, with the value set toeu-west-1a
--balancing-ignore-label="[topology.ebs.csi.aws.com/zone]"
flag setWhen the pod first becomes unschedulable, everything works as expected:
And eventually:
While the node is starting, again everything looks fine:
But once the new node (
ip-172-22-160-90.eu-west-1.compute.internal
) has joined the cluster and isReady
, there is an issue:And we start the scale up loop again:
And the same node group is scaled up again:
~10 seconds later, the autoscaler now sees that the pod can be scheduled on the node:
But by this point the additional scale-up is already happening.
My assumption is that this is a race condition between autoscaler evaluating the new node and the EBS CSI driver adding the
topology.ebs.csi.aws.com/zone
label? If I add thetopology.ebs.csi.aws.com/zone
label statically to the node group so that instances have it as soon as they are started the problem goes away. But that feels like the incorrect way of doing things.Am I missing something obvious? Or perhaps we're configuring the autoscaler slightly incorrectly? Any suggestions of things to try would be really appreciated.