feat: support Karpenter v1beta1 nodeclaims #188
Conversation
| @@ -261,6 +306,10 @@ func (n *Node) NotReadyTime() time.Time { | |||
| } | |||
| n.mu.RUnlock() | |||
| if !notReadyTransitionTime.IsZero() { | |||
| // if there's a nodeclaim creation ts, use it if the node has never been Ready before | |||
There was a problem hiding this comment.
This is when the node went not ready. If that's non-zero, we should use it instead of the node claim creation time, right?
There was a problem hiding this comment.
The problem this addresses is when the transient Node (from the NodeClaim) is replaced by the actual Node. The not ready time resets, so this uses the cached NodeClaim creation time to replace the initial not ready transition time so the ticker keeps ticking when the real node registers rather than resetting.
The NodeClaim creation TS is set back to zero when the node goes Ready for the first time so that if the nodes goes Ready and then Unready, the ticker won't use the NodeClaim creation time and will properly use the nodeReadyTransitionTime.
There was a problem hiding this comment.
Sorry, I'm still now following :). Assume this situation:
- Node starts and goes ready
- 10 minutes later, node goes not ready
The status condition should have a non-zero not ready time, which we should return. That time should be at launch + 10 minutes. Doesn't this change make us return the node claim creation time?
There was a problem hiding this comment.
it's zero'd out in the Ready() func:
n.mu.RUnlock()
// when the node goes ready, remove the nodeclaim creation ts, if any
if ready {
n.mu.Lock()
n.nodeclaimCreationTime = time.Time{}
n.mu.Unlock()
}
return ready
Issue #, if available:
N/A
Description of changes:
Testing:
DEMO:
eks-node-viewer-node-claims.mov
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.