Extend TargetGroupBinding to allow lookup of target group by name rather than just arn

[gfcroft]

Is your feature request related to a problem?
I work on a project where we desire to:

• create load balancers and target groups via terraform and only manage their lifecycle via terraform
• use the Aws load balancer controller to expose some k8s services
• create individual helm chart deployments for each of our apps with TargetGroupBindings, so that they can be routed to via the relevant target group

Currently it is required for TargetGroupBindings (when the controller doesn't manage the load balancer itself) to map onto the required target group by providing the target group arn.

Because we won't necessarily know what the relevant target group arn will be ahead of time when we create our app helm charts, this makes it difficult to use TargetGroupBindings for our use case

Describe the solution you'd like
A description of what you want to happen.
TargetGroupBinding is extended with the ability to lookup the relevant target group by name - target group names are unique per region per account - https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html

Describe alternatives you've considered
A description of any alternative solutions or features you've considered

We have considered other solutions, given our constraints around terraform management of target groups and load balancers, such as making our own custom controller, or generating the required helm values in our helm deploy pipeline, but both of these would be poorer solutions than simply extending this controller

[M00nF1sh]

@gfcroft
I'm not familiar with terraform, is it possible to reference created targetGroup's ARN within targetGroupBinding?
e.g. use the output(ARN) of your TargetGroup resource as input to TargetGroupBinding.

from this stackoverflow question, it seems possible: https://stackoverflow.com/questions/69997106/terraform-use-output-variable-as-an-input-in-another-resource

If so, i think it's a better way to address this issue if you create both resource within terraform.

[gfcroft]

Hi @M00nF1sh, thanks for getting in touch.

In our use case, we create AWS resources like load balancers and target groups by using terraform, and we create kubernetes resources (e.g. deployments, services, TargetGroupBindings) by writing helm charts, then deploying these charts using the helm cli tool

helm upgrade -i  example-chart . -f example-chart-values.yaml

We don't want to use terraform to deploy the helm chart (so just handling this all in terraform to bypass the issue is out) nor do we want to somehow-or-other output values from terraform, to then load them into a generated values file which we feed into helm deployments (which would be unusual and would compromise the immutability of the deployment artefacts involved).

We also don't want to have the terraform code that creates the target groups in aws also go and directly create the TargetGroupBinding resource in the kubernetes cluster - there are a few reasons why but in short it would cause a lot of friction as the app charts which should own this kubernetes resouce (as it exposes their services) don't. I would also wonder if there could be issues if the target group binding was created some time before the k8s service (that it is supposed to be fronting) exists.

[ivankatliarchuk]

If I understood correctly, there is a pull request open for quite a while to solve a very same issue #2655

Any chance to have a look and address it?

[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

[lukaspj]

/remove-lifecycle rotten

[fatmcgav]

FYI, I've rebased #2655 into #3903... 🤞 that might get some traction :)