nodeclaim should contain a copy of what nodepool and nodeclass looked like at the time of creation

kubernetes-sigs / karpenter

Karpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.

Apache License 2.0

461 stars 158 forks source link

nodeclaim should contain a copy of what nodepool and nodeclass looked like at the time of creation #1118

Open tvonhacht-apple opened 4 months ago

tvonhacht-apple commented 4 months ago

Description

What problem are you trying to solve?

In order to debug drifts (or new configuration) understanding of what a drifted nodeclaim has changed would help. By writing this data into the nodeclaim at the time of creation, even after updating nodepool and nodeclass, what was the working configuration before would be easy accessible.

How important is this feature to you?

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

tvonhacht-apple commented 4 months ago

interested in working on the issue

njtran commented 4 months ago

We attach a status condition onto the node with the type of Drift that occurred. In the case of someone changing some of the static fields on the NodePool, such as changing the labels, it would say something like NodePoolDrifted. Is this enough?

tvonhacht-apple commented 3 months ago

we would want a full copy of it There are multiple options that I can think about:

store it in nodeclaim as information
store it in a configmap with same name as nodeclaim
maybe just logging it, so that could be used for debugging afterwards

jonathan-innis commented 2 months ago

In order to debug drifts (or new configuration) understanding of what a drifted nodeclaim has changed would help

What part of the NodeClaim isn't present that you would like to see? Are you thinking that we should create a copy of the EC2NodeClass to put in the NodeClaim rather than having it continue to be a reference? I think this is the only thing that isn't static. Other than this, the NodeClaim values that are present in the spec represent the state of the NodePool scheduling decision at the time of creation.