label nodes with the name of the autoscaling group they belong to (if they belong to one)

[tkellen]

What would you like to be added:
It would be extremely helpful for operators if nodes were labelled with the autoscaling group they belong to (if there is an autoscaling group associated with a given node). I think node.kubernetes.io/auto-scaling-group-name would be appropriate for this.

Why is this needed:
Alleviate the need to cross-reference autoscaling group instances in AWS with node names in kubectl.

I would be happy to submit a PR if this would be considered for acceptance. Let me know!

/kind feature

[k8s-ci-robot]

This issue is currently awaiting triage.

If cloud-provider-aws contributors determine 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.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mmerkes]

I don't think this is unreasonable as long as we don't need to add any additional API calls, and it looks like aws:autoscaling:groupName is set on the instances by ASG, so we can just read the tag and apply the label with no additional calls. Thoughts @cartermckinnon?

[cartermckinnon]

Sounds reasonable, looks like we'll get the tags from ec2:DescribeInstances. ASG guarantees that will be added at creation, not after launch: https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-tagging.html#tag-lifecycle

Took a look at the code paths and it's a bit of a mess. We should reuse the ec2:DescribeInstances response in our InstancesV2.InstanceMetadata implementation, we have a few redundant calls today. But we can pass this new label with the AdditionalLabels field.

I think we'll want to use a label under the *.k8s.aws namespace, not node.kubernetes.io

[tkellen]

🙏🏻🙏🏻 the complexity reduction this would bring to my k8s node group upgrade script would be massive 🤞🏻.

[mmerkes]

+1 to what Carter is saying. There's currently one well known label in the cloud provider: topology.k8s.aws/zone-id. Something like node.k8s.aws/auto-scaling-group-name might be the one.

[tkellen]

Is this something you're looking for an outside contributor to implement (not yet sure how I would test it or I would have made an attempt already) or should I sit tight and let y'all do your thing?

[cartermckinnon]

I'll put something together, I'd like to do some cleanup anyway 😄

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[tkellen]

I am seeing the following labels applied to new nodes:
eks.amazonaws.com/nodegroup
eks.amazonaws.com/sourceLaunchTemplateId
eks.amazonaws.com/sourceLaunchTemplateVersion

Out of curiosity, where was this implemented? I don't see it in this repo?

[mmerkes]

I am seeing the following labels applied to new nodes: eks.amazonaws.com/nodegroup eks.amazonaws.com/sourceLaunchTemplateId eks.amazonaws.com/sourceLaunchTemplateVersion

Out of curiosity, where was this implemented? I don't see it in this repo?

That's not part of the cloud provider. You must be using EKS Managed Node Groups, which applies those labels.

[tkellen]

Ah! That makes sense, you're absolutely right. So many clusters. So much config 😵‍💫.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[tkellen]

/remove-lifecycle-rotten

checking in again to see if y'all are desirous of a contribution for this? some small guidance on testing and the cleanup you'd hoped to implement would be enough for me to dig in, I imagine.