aws-load-balancer-controller [Feature] ability to configure target group names

#870 and #1899 added the ability to configure the load balancer names with the alb.ingress.kubernetes.io/load-balancer-name annotation.

It would nice to also be able to configure the name of target groups. It could use the same annotation or a dedicated one.

Mar 15 '22 19:03 guillaumecle

@guillaumecle, how do you intend to configure the target group names? The target groups are based on the backend service, and it can be shared across multiple ingresses. The target group name format is k8s--- and contain the aws tags to uniquely identify the resource. In addition you can configure specific tags per service which will be reflected in the target group tags.

What is your use case for a custom target group name?

Mar 16 '22 22:03 kishorj

Our target names currently look like k8s-namespac-mysupers-2eb7cacf16. In many cases, 8 is not enough character to properly identify the service. I would do something like this my-super-service-doing-great-things

I was thinking of using an annotation on the ingress. In case there are multiple ingresses using the same target group, it would reject the custom name (fallback on the default) or error out or pick one of the provided names (similar to the handling of load-balancer-name in case of shared load balancer) For the unique id, could it be possible to store it in a aws tag? how does it works for load balancer name?

My primary goal is to get more human readable/searchable target group name in cloud watch metrics, alb access logs and even just when browsing the list of target groups.

Mar 17 '22 00:03 guillaumecle

@guillaumecle, we use tags to identify target groups/load balancer resources, so the name doesn't matter to the controller. However, controller needs to ensure the name is unique. We can support annotation to specify a target name prefix via annotation on the service/ingress, and use the prefix+hash to make the target group name unique. Would this proposal satisfy your requirement?

/kind feature

Apr 20 '22 22:04 kishorj

I think that would work for us. Thanks.

Apr 21 '22 00:04 guillaumecle

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

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

/lifecycle stale

Jul 20 '22 00:07 k8s-triage-robot

/remove-lifecycle stale

Jul 25 '22 22:07 guillaumecle

+1. It would be nice to have this feature which will make the identification of ALB destinations much easier. Any ETA on when this can be made available? Atleast support to tag the target groups with custom labels?

Aug 02 '22 13:08 karthichu

I also agree that naming the target groups could be a useful feature, for example when monitoring the traffic handled by the target we may want to be able to clearly bind it to the service name, not guessing it from the X first letter.

Aug 04 '22 15:08 xeivieni

same here, we have both 80 and 443 listening and would like to see at first glance what targetgroup handles what traffic. as often times, the same service exposes multiple ports, we actually would not only need a custom prefix, but on top an option to include the service-port in the targetgroup's name

so there could be 2 annotations: alb.ingress.kubernetes.io/targetgroup-name-prefix and alb.ingress.kubernetes.io/include-serviceport-in-targetgroup-name

this would translate to

only prefix-annotation set: {custom_prefix}-{hash} (as outlined in earlier comments on this issue)
only serviceport-annotation set: k8s-{tags}-{port}-{hash} (the default as it is now, just enhanced by the serviceport)
both annotations set: {custom_prefix}-{port}-{hash}

is something in this direction possible?

Sep 14 '22 09:09 dev-hanz-ops

+1

Oct 03 '22 05:10 higauravkohli

+1

Oct 03 '22 05:10 a-tharva

+1

Oct 03 '22 09:10 paraspachpute

+1

Nov 16 '22 17:11 lucasfnds

+1

Nov 17 '22 07:11 ghost

+1

Nov 20 '22 01:11 gwynnebaer

+1

Jan 13 '23 10:01 andrey-iliyov

+1

Jan 26 '23 17:01 oleg-ku-32768

This would help in cases were a single ALB has multiple target groups behind it. Currently if you create an ingress object named "microservice-abc" on a namespace also named "microservice-abc" the generated target group is k8s-microser-microser-{10_random_chars} which is not quite helpful. Of course there's the ingress.k8s.aws/resource tag which clears things up but filtering by tag is not always possible, e.g creating a Keda ScaledObject based on the TargetGroup CW Dimension.