Nick Tran
Nick Tran
Fixed as part of https://github.com/kubernetes-sigs/karpenter/pull/1385 and https://github.com/kubernetes-sigs/karpenter/pull/1401
This is essentially different to how Karpenter currently thinks of upgrades. We do upgrades declaratively, by noticing nodes that aren't in-spec, and gradually upgrading them when the user says Karpenter...
So I believe that we already check if a pod is terminal (succeeded or failed) when considering the do-not-evict pod. https://github.com/aws/karpenter-core/blob/main/pkg/controllers/deprovisioning/helpers.go#L328-L334 https://github.com/aws/karpenter-core/blob/main/pkg/utils/pod/scheduling.go#L50-L52 Is there something I'm missing here? are you...
After poking around, I think I understand your request now. Looks like you want to bypass the annotation in the case that any of the containers have a problem that...
/remove-hold
> You could also imagine a way to do this through something like a CRD annotation that would set the default NodeClass through the discovery client (in a way very...
> Changing from using it in the hash to not using it in the hash is a breaking change. The hashing mechanism does currently recursively hash everything. You can imagine...
For comments in this issue regarding pods with `do-not-evict` being ignored, it's possible you were running into an issue fixed in v0.31.1 (PR: https://github.com/aws/karpenter-core/pull/583). For others who are experiencing continual...
Yep! If you have a pod with a `do-not-evict` annotation, Karpenter will not drain any of the pods on a node, but it will still cordon the node. A node...