[Feature] ability to configure target group names

[guillaumecle]

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

[kishorj]

@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?

[guillaumecle]

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.

[kishorj]

@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

[guillaumecle]

I think that would work for us. Thanks.

[k8s-triage-robot]

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

[guillaumecle]

/remove-lifecycle stale

[karthichu]

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

[xeivieni]

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.

[dev-hanz-ops]

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?

[higauravkohli]

+1

[a-tharva]

+1

[paraspachpute]

+1

[lucasfnds]

+1

[ghost]

+1

[gwynnebaer]

+1

[andrey-iliyov]

+1

[oleg-ku-32768]

+1

[GeorgeTsilias]

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.

[minhhoangvn]

+1

[oleg-ku-32768]

+1

[fernando1989mg]

+1 pleaseeeee

[szheliab]

+1

[akumar-99]

+1
I use promethus-cloudwatch-exporter and I want to setup grafana dashboards. Having custom target group names will be of great help.

[neilkuan]

+1

[HarshRohila]

+1

[rnasby]

+1

[frankh]

had a crack at it if anyone wants to take a look at my PR ^

[asychev]

+1

[bryan-rhm]

+1

[AndrewCharlesHay]

+1

[AndrewCharlesHay]

I made a contribution to @frankh's PR 😀

@gunzy83 why the thumbs down?

[gunzy83]

I made a contribution to @frankh's PR 😀

@gunzy83 why the thumbs down?

Every time someone +1's, those of us subscribed for updates get a pointless notification. I guess I just added another one by responding.

[thiborgesnvs]

There is a lot of people that need this feature to do better jobs and automations

Can I do something here to help and have this feature included ?

On my work we use a name pattern to identify all the assets and configurations and don't have for targets on LB cause some errors when other teams try understand our targets

Here is an example

LB Name --->

TG Names --->

[AndrewCharlesHay]

There is a lot of people that need this feature to do better jobs and automations

Can I do something here to help and have this feature included ?

@thiborgesnvs I'm not a maintainer but we've been working on this PR. @frankh seems to have stopped responding and I haven't had the opportunity to look into @M00nF1sh 's requested changes. You can try your hand at it if you want

[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

[kkashyap1707]

Any update on this annotation for target group ???

[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

[bryan-rhm]

/remove-lifecycle rotten

[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

[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

[DanielRailean]

any updates on this ?

[vc019]

This would be a handy feature, especially when using the target group created by the controller in other apps or controllers.

[vc019]

/remove-lifecycle rotten

[lauren-hinge]

+1'ing with some detail, as I'm not sure the PR that was opened to address this issue (which seems abandoned) actually resolves it.

If I want a single ALB pointing at more than one target group, and I want to differentiate the CloudWatch metrics by path -- the only dimension CloudWatch gives us is the target group name.

With that in mind, we only have the first 8 characters of the K8s Service name to work with, to differentiate those metrics.

So I personally am not looking to "globally" change the prefix for all target groups for a given ALB -- I'm looking for each target group's name to be configurable.

However, my use case (target group names by url path) is not generalizable, and I struggle to see how a solution within a single ALB's annotations could be.

So instead I'm wondering -- could we take advantage of group.name here? Ingress groups solve a similar pattern, where we're intentionally splitting an ALB's config into distinct Ingress resources we want to manage separately.

If every ingress in a given group can declare its own target-group-prefix (the annotation from that PR), and when merging the ingresses it can pass that context to the target group creation process (rather than having the annotations clobber each other), then I think many use cases would be solved.

Just a thought! But for now, I'm just going to hope all the helm charts I'm using let me set a prefix for service name, so I can jam context into the first 8 characters 😭