Ability to create TargetGroup against a service (without an ingress)

[uptickmetachu]

Is your feature request related to a problem?
My team would like to be able to create services that are shared between multiple ingresses.

1. One use case would be blue/green deployment. Each service would have a targetgroup (created via targetgroup name).
   The ingress can then point to either targetgroup with attributes and weights.

2. Another use case would be for multitenanted services. We currently deploy a shared group of pods for multiple tenants each with their own ingress for url routing.
   Currently each ingress will create it's own target group (with its own associated healthchecks) against the same shared set of pods.

Describe the solution you'd like

Create an AWS TargetGroup with one (1) or more Listeners without a Load Balancer solely with a K8S manifest that is being parsed by the AWS Load Balancer Controller.

The functionality is highly likely already there, what we need is a custom CRD being exposed called 'TargetGroup'.

Alternatively

Create a targetgroup for a service via an annotation.
The targetgroup should be created by a requested name.

Describe alternatives you've considered

1. Creating the TargetGroup with Terraform or CloudFormation, but this is suboptimal as then we have to manage not only K8s manifests for deployment, but also other infrastructure code (e.g. Terraform, cloud-formation).

2. Pointing multiple ingresses to a service. This creates multiple target groups for the same set of pods.

3. Using nginx-ingress (does not support ALB features)

Related to this closed issue: #3578

[shraddhabang]

Hi @uptickmetachu,
Thanks for reaching out about creating independent target groups with the AWS Load Balancer Controller. While this functionality isn't currently supported directly by the controller, we do have an alternative solution that might be suitable for your use case. We recommend using the TargetGroupBinding Custom Resource Definition (CRD) to manage your service. You can find more information about it here. The downside if this approach would be that you would need to manage the lifecycle of you target group outside of the controller. The controller will handle registering and deregistering your service pods with the target group. You can then use the actions annotation in your Ingress resource to attach the target group to your listener.

I do want to point out couple of points after reading your use-case and proposed solution:

Sharing Target Groups: It's important to note that a single target group cannot be shared across multiple Ingress resources unless you're using an Ingress Group. Since each Ingress typically provisions a separate Application Load Balancer (ALB), target groups cannot be shared between them. However, Ingress Groups can be a solution as all Ingress resources within the group share a single ALB.
Listeners and Load Balancers: You mentioned creating a target group with one or more listeners in your proposed solution. Listeners require a pre-existing load balancer, so this wouldn't be possible directly with target group creation.

If the TargetGroupBinding approach doesn't fully meet your needs, or if you have any further questions, feel free to provide more details about your specific use case. We're happy to explore alternative solutions or discuss potential future enhancements to the controller.

[uptickmetachu]

Thanks for reaching out about creating independent target groups with the AWS Load Balancer Controller. While this functionality isn't currently supported directly by the controller, we do have an alternative solution that might be suitable for your use case. We recommend using the TargetGroupBinding Custom Resource Definition (CRD) to manage your service. You can find more information about it here. The downside if this approach would be that you would need to manage the lifecycle of you target group outside of the controller. The controller will handle registering and deregistering your service pods with the target group. You can then use the actions annotation in your Ingress resource to attach the target group to your listener.

We have considered this and might add that functionality to our own internal operator but ideally would like it managed via the alb controller.

Thank you for mentioning the of a target group being bounded to 1 load balancer; that might be an issue for us so we'll need to think of something else.

Although I think there is still value in this feature (there doesn't appear to be any other CRD or operator to create target groups in the wild) I think the above limitation would mean we will need to look for another solution.