Check for existing ALB(s) before attempting to create new one(s)

[GiladTrachtenberg]

Describe the feature you are requesting

Add support for adopting existing ALBs when Gateway API and Ingress resources target the same load balancer name. Currently, when a Gateway resource is configured to use an ALB name that already exists (managed by an Ingress or a different stack), the controller attempts to call CreateLoadBalancer instead of recognizing the existing ALB, resulting in:

DuplicateLoadBalancerNameException: A load balancer with the same name 'my-alb' exists, but with different settings

The controller should detect existing ALBs by name and either adopt them (update tags and reconcile) or provide a clear error message explaining the conflict.

Motivation

This feature is critical for users migrating from Ingress to Gateway API. The current behavior forces users to either:

1. Use different ALB names and manage a complex DNS cutover
2. Delete all Ingress resources first, causing downtime
3. Manually orchestrate the transition outside the controller

A seamless migration path would allow teams to:

• Gradually migrate routes from Ingress to Gateway API while sharing the same ALB
• Avoid provisioning duplicate load balancers during transition periods
• Reduce migration risk and downtime

A similar issue has been reported before (see #3338 and #228) but a solution hasn't been provided Gateway API. The Gateway API beta release makes this increasingly important as more users will attempt Ingress → Gateway migrations.

Describe the proposed solution you'd like

Modify loadBalancerSynthesizer.Synthesize() in pkg/deploy/elbv2/load_balancer_synthesizer.go to check for existing ALBs by name before calling Create():

1. Add a new method findExistingLoadBalancerByName() that uses DescribeLoadBalancers with the Names parameter
2. Before creating an "unmatched" resource LB, check if an ALB with that name already exists
3. If it exists, adopt it by:
   • Adding/updating the tracking tags (elbv2.k8s.aws/cluster, gateway.k8s.aws.alb/stack, etc.)
   • Calling Update() instead of Create() to reconcile the desired state
4. If adoption fails due to incompatible settings (e.g., different scheme, VPC), provide a clear error message

This would enable both Ingress and Gateway API resources to share ownership of the same ALB when they specify the same loadBalancerName.

Describe alternatives you've considered

1. Fail-fast with helpful error: Instead of adopting, detect the conflict and return a descriptive error explaining why the ALB can't be created and suggesting remediation steps. This is safer but doesn't solve the migration use case.

2. Manual tag pre-seeding: Document a workaround where users manually add Gateway API tracking tags to existing ALBs before deploying Gateway resources. This is error-prone and requires AWS console/CLI access.

3. Parallel ALBs during migration: Use different ALB names and manage DNS cutover. This works but increases cost, complexity, and migration risk.

Contribution Intention (Optional)

• Yes, I am willing to contribute a PR to implement this feature
• No, I cannot work on a PR at this time

[zac-nixon]

Hi. I appreciate the well thought out issue. We're having @shuqz look into some migration processes for Ingress -> Gateway, starting next year. The key problem I see with this "adoption" approach is that we're using two sources of truth. The controller operates on constructing a desired state from the Kubernetes manifests and then applies the desired state to the AWS APIs. With more than one source of truth, it's unclear how we would fix conflicts. For the Ingress -> Gateway case, we require Kubernetes manifests to be applied (e.g. the Gateway, GatewayClass, routes) the adoption approach would not address that problem.

@shuqz will have some more detail next year on our Gateway API migration story.

[GiladTrachtenberg]

@zac-nixon Thanks for your response, and it's reassuring to hear that you already have someone looking into the migration processes from the traditional ingress controller to the gateway suite. However, I think the issue is mostly with the API calls, and the proposed solution would be fairly straightforward. Instead of directly creating the load balancer, simply check if it exists and act accordingly.

[zac-nixon]

I truly don't think it's straight forward as you're suggesting.

simply check if it exists and act accordingly.

There's a lot of details not being exposed here. How do you handle conflicting definitions? E.g. my ingress definition is internal while my gateway is internet-facing, what do I use? This is a really complex problem as I mentioned. It's extremely hard to have multiple sources of truth. It's also possible that your suggestion would allow load balancer hi-jacking, for example, if there is an lb in namespace ns-1 and I know the name of it, I can hi-jack your lb in ns-2 despite not having permission to ns-1.