GatewayAPI topology (DAG 1.0)

[eguzki]

https://github.com/Kuadrant/kuadrant-operator/pull/447 introduced the GatewayAPI topology (DAG) implementation

This (epic) issue tracks the usage of GatewayAPI topology (DAG) implementation by the different kuadrant controllers

• [X] Rate limiting wasmplugin controller #447
• [ ] Rate limiting limits controller #527
  • [x] #751
  • [x] #752
  • [x] #777
• [x] AuthPolicy controller #712 #713
• [X] DNS policy controller #638
• [ ] Controller adding kuadrant annotations on the gateways
• [x] Kuadrant controller #714
• [ ] Limitador Cluster Envoy controller #527
• [X] RateLimitPolicy controller #638
• [ ] TLS Policy controller

The GatewayAPI Topology

The controller builds what it is named "The GatewayAPI Topology". It reads ALL Gateways, HTTPRoutes and policies (only those the controller cares about) in the cluster. With all that info, the controller creates a new instance of the Gateway API topology as well as a set of indexes (another "view" of the topology) that can be queried. Interesting to note here that field indexers can optionally be added to the manager to build internal index caches. One example being implemented is an index to query "give me all the HTTPRoutes parenting Gateway A".

The current implementation of the "GatewayAPI Topology" does not use a k8s client to query Gateway API and kuadrant policies. Instead, fetching resources must be done externally and then the GatewayAPI topology receives a list of resources. It could be done otherwise and have generic function with a k8s client to build topology for a given policy of one kind. The main reason for the current implementation is to decouple GatewayAPI topology and the cluster. Meaning that I can build GatewayAPI topology from a set of resources filtered with some criteria.

The implementation assumes "cheap" operations of reading ALL the gateways, routes and policies. That assumption comes from the controller runtime k8s client that holds a cache. At least for list and get operations. That cache is being kept up to date in the background when there are updates/deletes in the objects triggered by kuadrant controllers or any other third party controllers or any other k8s API server user. Check for this comment with a verification of this "cheap" operation assumption. Indeed, the resource lists are cached across reconciliation events and controllers.

The topology implementation is based on a pure Directed Acyclic Graph data structure implementation that is totally decoupled from the GatewayAPI relations. On top of that, there is an implementation of the GatewayAPI topology which builds a graph from Gateways and HTTPRoutes. In the future, it can be extended for additional GatewayAPI API types. On top of the GatewayAPI topology, a number of indexes are created which are tailored for the needs of the kuadrant controllers. Thus:

Kuadrant controller 
       |
       |
       V
Custom topology indexes (views)
       |
       |
       V
GatewayAPI topology (focused on one gateway)
       |
       |
       V
     DAG