Jonathan Innis

I think in general it makes sense if the pod is in an errored state and is clearly not running, that disruption like this should be allowed. One thing I...

> This race conditions would only occur if a given pod is the only reason why the cluster scaled up in the first place Not neccesarily. Consolidation or expiration could...

> Yes I would like to ignore pods which have containers wich will never recover from a terminal state but I would also like to simple ignore pods which are...

> The pod is in pending state and the container is in waiting state, here is a similar example Is it possible to get this at the source and remediate...

What's your Provisioner look like as well as your `karpenter-global-settings`? Karpenter uses a concept called `vmMemoryOverheadPercent` since all EC2 instances come with some unknown overhead that is consumed by the...

> Would you suggest to increase aws.vmMemoryOverheadPercent I was able to repro this and I'd recommend to bump this up to a higher value `0.08` as a workaround. > Shouldn't...

> was not enough for us Which instance types are you using that required you to bump it up to `0.1`?

@project-administrator Linking https://github.com/aws/karpenter-core/issues/751 since it has the details of extended resource support for a bunch of different things, including `hugepages`. I'm not as familiar with hugepages and how it affects...

After some discussion with the EBS CSI Driver team, I think the real solve here is for the client-side drain behavior to actually wait on the volume detachment since that...

> This feature is important to avoid successive instance disruptions, we already have configured that a maximum of one instance may be disrupted during the disruption phase @ccortinhas-pmi Can you...