Open rrmarq opened 2 months ago
This issue is currently awaiting triage.
If Karpenter contributors determines this is a relevant issue, they will accept it by applying the triage/accepted
label and provide further guidance.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
Are the values for AMI_ID
and INSTANCE_ID
being fetched from IMDS? Then propagating that to labels in their userData. I'm not sure how we would do this, as this would require parsing IMDS's internally structured data into labels that they can use, which can really only be done without a structured userData (not bottlerocket or AL2023 iiuc).
The way to do this in Karpenter would be to add these as first class labels, where they're either propagated after the result of the cloudprovider.Create() call or reconciled onto the node after the fact.
Are these labels used for anything like scheduling constraints? Or is it purely for monitoring purposes? What are the full set of labels you pull from IMDS? Also this issue should probably live in https://github.com/aws/karpenter-provider-aws
Yes, today the values are fetched from IMDS
Are the values for AMI_ID and INSTANCE_ID being fetched from IMDS?
Description
What problem are you trying to solve? Have instance metadata values as labels
How important is this feature to you? My internal observability tools make use of the AMI_ID and INSTANCE_ID, which we set to the lables LABEL_AMI_ID and LABEL_INSTANCE_ID respectively. Currently we are setting these labels in the userData, however, doing this way we cannot make use of the AL2/AL2023 AMIs. We need theses labels being set by Karpenter so that we can use auto-generated userdata.