Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tags in managed node groups #1571

Closed
derrickburns opened this issue Nov 18, 2019 · 20 comments
Closed

Tags in managed node groups #1571

derrickburns opened this issue Nov 18, 2019 · 20 comments
Labels
area/managed-nodegroup EKS Managed Nodegroups kind/improvement needs-investigation priority/important-longterm Important over the long term, but may not be currently staffed and/or may require multiple releases

Comments

@derrickburns
Copy link

Tags (managedNodeGroups[*].tags) in managed nodegroups apply to the EKS Nodegroup resource and do not propagate to the provisioned Autoscaling Group like in unmanaged nodegroups.

Does this mean that tags will not get applied to instances and that the cluster autoscaler will not work?

@derrickburns derrickburns added the kind/help Request for help label Nov 18, 2019
@whereisaaron
Copy link

There is supposedly built-in support for cluster-autoscaler tags. This will only work if AWS automatically tags the ASG for the node group taints and labels, without then you can't scale from zero.

https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html

Amazon EKS tags managed node group resources so that they are configured to use the Kubernetes Cluster Autoscaler.

Important
If you are running a stateful application across multiple Availability Zones that is backed by Amazon EBS volumes and using the Kubernetes Cluster Autoscaler, you should configure multiple node groups, each scoped to a single Availability Zone. In addition, you should enable the --balance-similar-node-groups feature.

@johnpetersjr
Copy link

I have experienced that when setting tags on a NodeGroup, the tags will propagate to the ASG and to the EC2 instances.

When settings tags on a managedNodeGroup, the tags do NOT propagate down to the ASG or EC2.

@sashasimkin
Copy link

Is there a way to tag corresponding ASGs and instances?

@galindro
Copy link

galindro commented May 28, 2020

According to https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html, Amazon EKS managed node groups do not supports tag propagation yet. Currently, we would need to do some code to find the associated ASGs and tag them

@TBBle
Copy link
Contributor

TBBle commented May 29, 2020

aws/containers-roadmap#608 is the AWS containers roadmap issue tracking this feature.

@TBBle
Copy link
Contributor

TBBle commented May 29, 2020

For Cluster Autoscaler specifically, the EC2 instances and Auto Scaling Groups created for Managed NodeGroups are automatically tagged with the expected labels:

k8s.io/cluster-autoscaler/enabled:true
k8s.io/cluster-autoscaler/<clustername>: owned

@michaelbeaumont michaelbeaumont added area/managed-nodegroup EKS Managed Nodegroups kind/improvement and removed kind/help Request for help labels Jun 24, 2020
@github-actions
Copy link
Contributor

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions
Copy link
Contributor

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions github-actions bot added the stale label Feb 18, 2021
@TBBle
Copy link
Contributor

TBBle commented Feb 18, 2021

It seems the recommended way to apply tags to EC2 instances in EKS Managed Node Groups is using Launch Templates, which eksctl supports. Is that sufficient to fulfill this feature request?

Cluster Autoscaler doesn't depend on tags on the EC2 instances, it depends on tags on the ASG, which are still unable to be customised per aws/containers-roadmap#608.

@michaelbeaumont
Copy link
Contributor

michaelbeaumont commented Feb 18, 2021

Seems like we could just set the tags on the launch template, since eksctl always uses launch templates

@michaelbeaumont michaelbeaumont added priority/important-longterm Important over the long term, but may not be currently staffed and/or may require multiple releases and removed stale labels Feb 18, 2021
@aclevername
Copy link
Contributor

The managedNodeGroups[*].tags field already gets added to the launch template spec:
https://github.com/weaveworks/eksctl/blob/da899ad2176936d1045dc365ea3bba44647858c1/pkg/cfn/builder/managed_launch_template.go#L145-L164

This adds the tag to all EC2 instances. You still cannot add tags to the ASG aws/containers-roadmap#608 (comment)

@aclevername
Copy link
Contributor

I'm going to close this issue as the original intent of this was to be able to tag the EC2 instances, which you can.

It seems the recommended way to apply tags to EC2 instances in EKS Managed Node Groups is using Launch Templates, which eksctl supports. Is that sufficient to fulfill this feature request?

Cluster Autoscaler doesn't depend on tags on the EC2 instances, it depends on tags on the ASG, which are still unable to be customised per aws/containers-roadmap#608.

I think if/when EKS add support for tagging the autoscaler it will likely be a no-op from our end, as we are already tagging the nodegroup and launch template, so its likely that if it was ever implemented the ASG would inherit the tags from one of those two.

@afirth
Copy link

afirth commented Mar 23, 2022

@aclevername Without this change, cluster-autoscaler scale up from 0 (eksctl docs) doesn't work with managed node groups.
Is it that eksctl can't implement this, or doesn't prioritize? If the latter, are you open to community contributions?
Either way, I'd like to reopen this for either a docs update to make it clear that it only works with unmanaged node groups, or a fix. The upstream issue is at 500 votes and still in "researching" - unlikely to be implemented I guess

@aclevername
Copy link
Contributor

aclevername commented Mar 23, 2022

are you open to community contributions?

absolutely!

Either way, I'd like to reopen this for either a docs update to make it clear that it only works with unmanaged node groups, or a fix. The upstream issue is at 500 votes and still in "researching" - unlikely to be implemented I guess

👍

@aclevername aclevername reopened this Mar 23, 2022
@aclevername
Copy link
Contributor

@Himangini

@Himangini
Copy link
Collaborator

@aclevername isn't this related to what @Skarlso is working on here #4853 🤔 maybe I am missing something.

@afirth thanks for your comments, we are happy to accept PRs if you have a fix in mind 🙌🏻 🎉

SlevinWasAlreadyTaken added a commit to SlevinWasAlreadyTaken/eksctl that referenced this issue Mar 24, 2022
Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be disabled using DisableASGTagPropagation boolean in the
configuration.

Issue eksctl-io#1571
@cPu1
Copy link
Contributor

cPu1 commented Mar 29, 2022

Tags (managedNodeGroups[*].tags) in managed nodegroups apply to the EKS Nodegroup resource and do not propagate to the provisioned Autoscaling Group like in unmanaged nodegroups.

Please note that this behaviour has changed to:

Tags (managedNodeGroups[*].tags) in managed nodegroups apply to the EKS Nodegroup resource and to the EC2 instances launched as part of the nodegroup.
They do not propagate to the provisioned Autoscaling Group like in unmanaged nodegroups.

@afirth
Copy link

afirth commented Mar 29, 2022

#5002 is open for review to fix this.
@cPu1 the problem with that is that cluster autoscaler is looking at the ASG tags

SlevinWasAlreadyTaken added a commit to SlevinWasAlreadyTaken/eksctl that referenced this issue Mar 30, 2022
Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be enabled using propagateASGTags boolean configuration.

Issue eksctl-io#1571
SlevinWasAlreadyTaken added a commit to SlevinWasAlreadyTaken/eksctl that referenced this issue Apr 5, 2022
Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be enabled using propagateASGTags boolean configuration.

Issue eksctl-io#1571
SlevinWasAlreadyTaken added a commit to SlevinWasAlreadyTaken/eksctl that referenced this issue Apr 11, 2022
Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be enabled using propagateASGTags boolean configuration.

Issue eksctl-io#1571
SlevinWasAlreadyTaken added a commit to SlevinWasAlreadyTaken/eksctl that referenced this issue Apr 11, 2022
Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be enabled using propagateASGTags boolean configuration.

Issue eksctl-io#1571
SlevinWasAlreadyTaken added a commit to SlevinWasAlreadyTaken/eksctl that referenced this issue Apr 13, 2022
Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be enabled using propagateASGTags boolean configuration.

Issue eksctl-io#1571
SlevinWasAlreadyTaken added a commit to SlevinWasAlreadyTaken/eksctl that referenced this issue Apr 13, 2022
Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be enabled using propagateASGTags boolean configuration.

Issue eksctl-io#1571
SlevinWasAlreadyTaken added a commit to SlevinWasAlreadyTaken/eksctl that referenced this issue Apr 21, 2022
Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be enabled using propagateASGTags boolean configuration.

Issue eksctl-io#1571
SlevinWasAlreadyTaken added a commit to SlevinWasAlreadyTaken/eksctl that referenced this issue Apr 21, 2022
Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be enabled using propagateASGTags boolean configuration.

Issue eksctl-io#1571
SlevinWasAlreadyTaken added a commit to SlevinWasAlreadyTaken/eksctl that referenced this issue Apr 22, 2022
Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be enabled using propagateASGTags boolean configuration.

Issue eksctl-io#1571
SlevinWasAlreadyTaken added a commit to SlevinWasAlreadyTaken/eksctl that referenced this issue Apr 22, 2022
Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be enabled using propagateASGTags boolean configuration.

Issue eksctl-io#1571
Skarlso pushed a commit that referenced this issue Apr 25, 2022
…oScalingGroups (#5002)

* Added Propagation of ManagedNodeGroup Tags to their AutoScalingGroups

Changes	to ensure that AutoScalingGroups Tags are the same as their
 ManagedNodeGroup.

All tags are copied from the ManagedNodeGroup to the AutoScalingGroup.
If the tags already exists, it is overridden.

This is the default behaviour (as it is for Unmanaged NodeGroup) and
can be enabled using propagateASGTags boolean configuration.

Issue #1571

* Update generated files

* fix existing unit tests

* update documentation

* Update generated files

* consider new way of configuring tags propagation after the rebase

* re-add disableASGTagPropagation doc for managed nodegroup

* consider tags limits, move logic to a more appropriated place, re-add test for managernodegroup

* fix usage of aws-sdk-go-v2, improve task parallelisation for managednodegroup creation

* fix test linting

* add unit tests

* improve unit test structure for PropagateManagedNodeGroupTagsToASG, rename astypes package to asTypes

* use const for auto-scaling-group string

* improve some code structure
@afirth
Copy link

afirth commented Apr 25, 2022

I think #5002 didn't link in a way to autoclose, but this is implemented there and should be closed?

@Skarlso
Copy link
Contributor

Skarlso commented Apr 25, 2022

Yep. Thanks! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/managed-nodegroup EKS Managed Nodegroups kind/improvement needs-investigation priority/important-longterm Important over the long term, but may not be currently staffed and/or may require multiple releases
Projects
None yet
Development

No branches or pull requests