[feat aga] Add AGA listener support without auto-discovery

[shraddhabang]

Description

This PR introduces the AGA listener lifecycle management in AGA controller. It has two commits as follows.

1. [feat aga] Add AGA listener builder without auto-discovery

This commit introduces the model builder changes for AGA Listener Resources & Port Range Validation

• Model Builder for Listener Resources: Updated the listener model builder to directly use values specified in the CRD spec. We plan to set these values based on endpoints with auto-discovery if not specified. We will implement that later. This is simple implementation which directly builds object from CRD specs.

• Port Range Validation Webhook: Implemented validation logic that prevents overlapping port ranges between listeners with the same protocol if specified in CRD. We will extend the same validation during auto-discovery.

  • Groups port ranges by protocol (TCP/UDP)
  • Checks for overlaps within each protocol group
  • Returns validation errors when overlapping port ranges are detected

2. [feat aga] Add AGA listener deployer with clean up

This PR implements the complete AGA Listener deployer, which reconciles listener resources defined in Kubernetes with the AGA service with Intelligent Matching Algorithm.

Key Features

• Two-phase Listener Matching Algorithm: Implements a sophisticated matching algorithm that:

  1. First attempts to find exact matches based on protocol and port ranges
  2. Then falls back to similarity-based matching for remaining unmatched listeners
  3. Uses a scoring system that considers protocol, port overlap, and client affinity
  4. Minimizes resource churn by reusing existing listeners where possible

• Optimized Operation Order: The deployer performs operations in an order that minimizes service disruption:

  1. Delete only conflicting listeners that block updates
  2. Update existing matched listeners
  3. Delete non-conflicting unmatched listeners
  4. Create new listeners as needed

• Comprehensive Test Suite: Includes extensive test cases that verify:

  • Port conflict detection in various scenarios
  • Key generation for consistent matching
  • Similarity score calculation for partial matches
  • The complete matching workflow with both exact and similarity matches

Cleanup Logic

The current implementation includes a simple cleanup mechanism that safely removes listeners while cleaning up the accelerators. A more sophisticated cleanup strategy that considers endpoint groups and other dependent resources will be implemented separately once all Global Accelerator resource types are supported. Future PRs will enhance the cleanup logic with more sophisticated resource dependency tracking once all GA resource types are supported.

Checklist

• Added tests that cover your change (if possible)
• Added/modified documentation as required (such as the README.md, or the docs directory)
• Manually tested
• Made sure the title of the PR is a good description that can go into the release notes

BONUS POINTS checklist: complete for good vibes and maybe prizes?! 🤯

• Backfilled missing tests for code in same general area 🎉
• Refactored something and made the world a better place 🌟

[zac-nixon]

Is there any implicit defaults that we need to worry about here? E.g. if the protocol is missing then it's assumed to be TCP. If that's the case, we will always say that the listener setting has drifted. We run into this problem with quite a few ELB features.

[emdelaney]

Client Affinity defaults to NONE: https://docs.aws.amazon.com/global-accelerator/latest/api/API_CreateListener.html

The ports and protocols must be specified.

[shraddhabang]

Thanks. I was just confirming this. We will always set Protocols and Ports from our model build. And Client Affinity is None by default in our case too. So we wont see the false drift problems.

[zac-nixon]

interesting approach, this would be useful for updating ELB listener rules as well. Is this similarity score based off of a well-known algorithm?

[shraddhabang]

The idea came from hamming distance algo and Jaccard Index which are standard similarity algorithms. I had this algorithm idea when I was working with rules management for ELB. But it seemed complex for it since our rules are much more complex. I was worried about performance at that time. So never actually implemented it.
Since the AGA listeners were much more easier structures, it was easier to implement the algo on them and I did not want to repeat our rules problem again. But I think we can definitely give it a try now for our rules management as well.

[zac-nixon]

Thanks for the thorough explanation. I find it helpful to detail the algorithm in the code itself. That way developers don't need to come in find these PR comments when working on this piece of code.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: shraddhabang, zac-nixon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [shraddhabang,zac-nixon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment