label nodes with the name of the autoscaling group they belong to (if they belong to one) about cloud-provider-aws HOT 11 OPEN

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.

from cloud-provider-aws.

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?

from cloud-provider-aws.

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

from cloud-provider-aws.

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

from cloud-provider-aws.

+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.

from cloud-provider-aws.

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?

from cloud-provider-aws.

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

from cloud-provider-aws.

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

from cloud-provider-aws.

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?

from cloud-provider-aws.

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.

from cloud-provider-aws.

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

from cloud-provider-aws.